System requirements
Functional:
Client will provide startdatetime and enddatetime and be shown available spots
Reservations will have a per hour and a per day rate and customer will be charged whichever is lower for their reservation
Customers will be charged the full amount if they do not cancel by the start of the reservation
Customers will be designated a particular spot and notified at time of reservation which spot they are at
Non-Functional:
Reservation system should be fairly reliable 99.9%
We need to ensure ACID compliance to not double book parking spaces
Capacity estimation
We will handle average of 100 garages in 10 countries. Each of these garages could support an average of 200 spaces per lot meaning 200,000 parking spots would be in management. Each parking spot will be represented as having
GarageId [2 bytes]
Spot Id [4 bytes]
Parking Label[3 bytes]
This will be some 10s of megabytes.
Reservations each need the following space allocation:
ReservationId [4 bytes]
ReservationStatus (PROPOSED,CONFIRMED,CANCELLED) [1 byte]
UserId (maybe unknown in state PROPOSED) [4 bytes]
ParkingSpotId [4 bytes]
GarageId [2 bytes]
StartDate [4 bytes]
EndDate [4 bytes]
}
Assuming reservations of 50% of the spots start each day (this is generous) we would get 100,000 reservations a day each with a total of 23 bytes which is 2.3 megabytes/day. Over the course of the years it could enter into gigabutes.
API design
returns all the garages (about 1000) to the client
getAllGarages(
{{
garageId
address
latlng
imageUrl
},
}
// Returns a proposed parking reservation that expires
// in 15 minutes
requestParkingFares(GarageId, startDateTime, endDateTime)
returns
{
garageId:
description:
price:
}
reserve(GarageId, startDateTime, endDateTime, paymentInformation)
returns {
reservationId:
amountPaid:
garageId:
}
cancel(ReservationId)
Database design
UserTable
UserId
Name
Address
BankingInfo
Garage
GarageId
GarageAddress
ParkingSpot
ParkingSpotId
ParkingLabel
GarageId
ReservationTable {
ReservationId
ReservationStatus (PROPOSED,CONFIRMED,CANCELLED)
UserId (maybe unknown in state PROPOSED)
ParkingSpotId
GarageId
StartDate
EndDate}
Create Index on ReservationTable Column GarageId
High-level design
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
We use a basic design with a gateway to handle requests and sending them to a proper sharded Reservation Microservice. Since there are only millions of parking space the whole database can be accessed through a cache. It can be partioned globally since people tend to access parking garages near where they are so that will give us some level of optimization. We use an RDBMS like postgres and keep consistency.
Request flows
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Client makes request through to the gateway API fronted This will handle authentication, and load balancing, and ratelimiting. The request will be forwarded to the reservation microservice. Requests that access database will go through the cache and if failed go through database and load the free parking data into it
The cache will be write through cache and will have access to available parking spots as well as reservations so it can quickly calculate available spots in a garage and return 1 to custmer
The free spaces will be calculated using the ReservationTable (indexed by garage) and the garage table. Since this is some few hundred rows this should be a minimal algorithm to compute in memory.
A spot will be calculated when its reserved to minimize accidental double bookings
Detailed component design
Trade offs/Tech choices
Using RDBMS for ACID compliance. We have included a cache that will increase complexity but make queries a little bit faster. Given the size of the dataset it may be possible to remove it.
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
If there is some important event it is possible that many peop;le book at one garage at once. We are careful not to display which spot a user has until the reservation is confirmed so we shouldn't get into too many attempts at reserving a spot twice.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Handle no shows better than just charging them. Server side retries can be used in the event of a double booking.