System requirements

Functional:

• users can reserve a parking slot
• users can also walk in to check the available parking slots
• users make payment when they exit the parking lot

Non-Functional:

• The system has to be consistent to avoid double booking on the same slot
• The system has low latency

Capacity estimation

Assume we have a parking lot with 500 parking spots. Each spot has 12 cars parked on average everyday. Then we'll have 500 * 12 * 365 = 219000

For each parking, we should have info like car plate number, parking id, start time, end time, etc. Assume each parking info is 1KB, then the total storage is 219000 * 1KB * 5yrs = 11GB

API design

• reserve (slot_id, car_id, start_time) - user can reserve a parking lot in advance and be given a confirmation code
• check-in(slot_id, car_id, start_time) - if already reserverd with confirmation code, then print a ticket and let it it; Otherwise check the availability of parkings, and assign a slot_id to this car.
• check-out(ticket_id)

Database design

• parking_slot (slot_id, status)
• reservation(slot_id, car_id, start_time)
• ticket(slot_id, car_id, start_time, rating) - no matter with or without reservation, a user has to get a ticket when they check in.

High-level design

Request flows

Reserve a slot

• A user send a request to service to reserve a slot ->
• The request will be routed to the appropriate server by the load balancer ->
• The server check the availability of the parking slots for the requset day ->
• The user select the slot and confirm the reservation

check-in

• A user arrive the parking lot for checking in ->
• If arleady reserved, then he scan the code and get a ticket; otherwise, the server will find an available parking lot for the user, and print a ticket for him

check-out

• A user exit the parking building, insert the ticket to the validation machine ->
• The server will calculate the fee based on rating, start_time, end_time for the parking ->
• The user insert credit car, cash, or anyother payment ->
• Payment go through and send back with a receipt

Detailed component design

If the system is reserved but the user does not show, the system will still start charging based on the start time and rating. If the user still does not checkin with 24 hours, then this reservation will be cancelled, and the user will be charged for 24 hours parking fee.

Trade offs/Tech choices

Consistency vs availability

When user is booking a parking lot, we should ensure the consistency of the data to avoid double booking on the same lot.

Failure scenarios/bottlenecks

To avoid single point of failure, we should replicate the database. The master node is used to handle all the write queries, and slave nodes are used to handle all the read requries.

Future improvements

If there are more and more parking buildings, then we need to consider a distributed system which may require database partitioning.