Loading...
users are able to check remaining spots in real time;
remaining spots are updated when vehicles enter & exit the parking lot
100 ~ 200 peak read qps
reliable, scalable
read consistency doesn't have to be strong (users can get slight outdated data)
100 ~ 200 peak read qps
support ~ 500 vehicles maximal
~50 parking lots
takes about 1 min for a vehicle to enter or leave a parking lot, so write qps is at most 50 * 2 (because enter + exit) / 60 = 1.67, which is relatively low
REST APIs for write (enter & leave parking lot)
/v1/enter
request: {
Enum vehicleType (can be car, motorbike, van),
Int parkingLotId
}
response {
boolean successful
}
/v1/exit
request: {
VType vehicleType (can be car, motorbike, van),
Int parkingLotId
}
response {
boolean successful
}
Read API
checkAvailableSpots
request {
list
}
response {
Map
}
since the data size is relatively small and write qps is limited, we can use a relational db to hold the data
int parkingLotId
int remainingCarSpot
int remainingMotorBikeSpot
int remainingVanSpot
...
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...
Database:
the data size is small (we don't need partition), all the requests come from the same region (no need for multi data center).
That being said, we can add replicas to provide reliability and prevent data loss, as well as scaling the system to support 100 ~ 200 peak read qps
For write operations, we can utilize relational db's own ACID and guarantee data consistency during concurrent write. And due to the nature of parking lot, it's unlikely we will see concurrent write of the same parking lot id
For read operations, since we can compromise consistency a little bit, we can directly serve the request without holding a lock, and directly read from replicas.
compromise read consistency to support a higher read qps
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?