System requirements

Functional:

1. Users can reserve a spot to park
2. Users can walk in and park
3. If a user no show after 24h of a reservation, we charge the fee for the first day

Non-Functional:

1. Consistency - if the parking lot is full, we shouldn't let user in
2. Highly available
3. 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

1. check_capacity(lot_id, vehicle_type, start_time, end_time)
2. reserve(user_id, start_time, end_time, vehicle_type, lot_id)
3. cancel_reservation(reservation_id)
4. check_in(user_id, vehicle_id, time)
5. check_out(user_id, vehicle_id, time)

Database design

User

user_id

name

email

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

1. Parking server - check capacity
2. Reservation server - create reservation
3. offline job - check for no show reservation, put the charging request on the queue
4. 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 , and > in cache.

Database

The size of data is still small, we can replicate the entire database using master-slave pattern.

Trade offs/Tech choices

1. Database choice - choose SQL over NoSQL because the data size is relatively small, and we require strong consistency.
2. 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?