Loading...
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
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.
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
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
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
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.
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.
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
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?