Loading...
My Solution for Design an Efficient Parking Lot System with Score: 9/10
by zephyr_cosmos528
System requirements
Functional:
- Users can reserve a spot to park
- Users can walk in and park
- If a user no show after 24h of a reservation, we charge the fee for the first day
Non-Functional:
- Consistency - if the parking lot is full, we shouldn't let user in
- Highly available
- Latency - can be relaxed a little bit, it's acceptable for the reservation step to take a few seconds.
Capacity estimation
Assume the system manages 10 parking lot with 500 spots each. Assume during peak, 10 cars exit/in per minute. Assume 50 reservations per day.
TPS
Exit/in: 10 * 2 / 60 = 0.33
Reservation: 5
Storage
Per entrance, user data is around 50b, vehicle data 50b, reservation 80b
180b * 50 request/day * 10 lot *2 years = 65.7MB
API design
- check_capacity(lot_id, vehicle_type, start_time, end_time)
- reserve(user_id, start_time, end_time, vehicle_type, lot_id)
- cancel_reservation(reservation_id)
- check_in(user_id, vehicle_id, time)
- check_out(user_id, vehicle_id, time)
Database design
User
user_id
name
Vehicle
vehicle_id
type (enum)
user_id
plate
Reservation
reservation_id
user_id
vehicle_id
start_time
end_time
lot_id
status(confirm, complete, cancel)
payment_status(unpaid, cancelled, fulfilled)
Parking Lot
lot_id
location
Lot_Capacity
capacity_id
lot_id
vehicle type
available
Spot
spot_id
lot_id
vehicle type
status
Transaction
tx_id
user_id
vehicle_id
start_time
end_time
High-level design
- Parking server - check capacity
- Reservation server - create reservation
- offline job - check for no show reservation, put the charging request on the queue
- Cache - cache the parking lot info and spot info
Request flows
Reservation
Load balancer dispatches the request to the parking server to check capacity based on the vehicle type and parking lot id. If spot available, reservation server creates a reservation and saves to the database. If walk in, the reservation server creates a reservation on the fly.
Check in/out
When user arrives, the parking server records the check in time, after s/he parks, the system update database and cache with the updated reservation status, and the capacity.
When user checks out, the parking service calculates the rate and queues the payment request for payment service to process.
Detailed component design
Cache
To improve the performance of get_capacity API, we store the
Database
The size of data is still small, we can replicate the entire database using master-slave pattern.
Trade offs/Tech choices
- Database choice - choose SQL over NoSQL because the data size is relatively small, and we require strong consistency.
- Spot assignment - instead of assigning a specific parking spot when making reservation, we only keep a record of the capacity of each vehicle type for more efficient space allocation.
Failure scenarios/bottlenecks
Need to keep cache in sync with the database
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Markdown supported