System requirements
Functional:
User can search for parking spots in a certain location that are open over a certain period of time -> shows the parking spots and the price of that reservation
User can then opt to reserve that spot
Non-Functional:
Since we assume 100,000 users using the parking lot per day we need to be able to handle on average 100000/24 reservations per hour, this should be low latency and be able to handle hot periods where it's more like 100000/12 reservations per hour for 200000 parking spots
Parking reservations should be consistent (once booked that should be consistent)
Available to view the parking lots -> we can prioritize updating the parking information by location.
Capacity estimation
We have about 200000 parking spots that need to be stored
User reservations average 100000 per day and 100000/24 per hour our system should be able to handle that amount of traffic while maintaining consistency
API design
GET /location: show available parking spots fitting user query for spots
POST /reservation: get a possible spot at a location showing price -> makes a reservation that is pending
PUT /reservation/id: sent a reservation to either open or cancelled and then update the parking spot appropriately
Database design:
Parking Spots (index by location):
primary_key_id
location_id
price
time start
time end
reserved: open | pending | closed
Location (index by coordinates):
primary_key
coordinates
time start
time end
price at location
User:
primary_key
name
reservation:
primary_key
user_id
parking_spot_id
time range
status: in progress | closed
High-level design
Firstly we need to handle the scalability of the requests per minute which is 100000/48 during a hot period. This means it could be beneficial to have a queue for fetching the location information like price at a time
We can index the location db by coordinates
In order to keep parking spot reservations consistent is that we have a lock with a ttl when a user is checking out a reservation they have a time to lock that spot so other people can't double park
For availability we can have a system to cache location information by region like CDN, so that for example users in America can more quickly be served information on parking spots in america.
Request flows
The user requests location information: the fetch location service goes to the database and gets the location that fits the user's query and returns the price and availability to the user
The user can then checkout an individual parking spot -> status of spot is sent to pending and reserve or cancel that updating the status appropriately.
Detailed component design
Queue for the user viewing parking lots and checking out individual parking lot spots
Lock for the parking lot spots with a ttl to prevent double booking
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?