System requirements
Functional:
- Users should be able to pay for and reserve parking spot at a particular parking garage by giving a location, time, duration, car size, and EV or not specification
- Users should be able to cancel parking requests 24 hours before their appointment time
- If an appointment is made successfully users should be guaranteed a spot
- Users should be able to extend their parking
- Users should be able to search for parking garages based on location
Non-Functional:
- Strong consistency is important. Users should never be able to double book
- Protection against malicious overbook requests like requiring an authenticated email or json webtoken
- Analytics telling us hot spots of parking areas that are commonly booked full for future development considerations (buying more lots)
Capacity estimation
- Assume a nationwide company with 1000s of parking spots
- Each spot has around 200 spots, and sees 500 or so people a day on average. The request contains 2 timestamps, start and end time, location (a 10 char string), some identifying information about the user like name (20 chars), type of car, so around 152 bytes.
- 152 * 1000 * 500 ~ 76,000,000Mb of data per day. This can be handled by a single relational database like postgreSQL
API design
POST /parking/:location/submit -> reservation_id {
user_id: string
car_type: int
car_size: int
start_time: ISO 8601
end_time: ISO 8601
}
POST /parking/modify -> confirmation {
reservation_id: string
end_time: ISO 8601
}
GET /parking/view_reservation -> reservation_details {
reservation_id: string
}
Database design
This design is ammenable to a relational database. As mentioned previously a basic SQL database like postgreSQL is probably sufficient.
We can multi index based on reservation start time, user_id, and reservation_id since queries will most likely target a range of dates or a particular user or reservation ID.
The throughput of the system is not that high but if we can add some redundancy via replication that is natively supported by postgreSQL
High-level design
Simple client talking through an API gateway to the server should be sufficient. There's no real need for too many multiple servers but it would be useful to have a replication of servers for robustness. Server receives RESTful commands and translates them to database updates or lookups and queries the postgreSQL database.
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...
Detailed component design
The most likely to be scaled part of this design is the parking request and update. This can easily be scaled horizontally by sharding the database by geographical location and having a server handling each of the geographical locations.
Similarly, we can speedup reservation lookup requests by using something like redis to cache currently valid parking requests up to the furthest out in the future we allow reservations in a circular buffer and update every hour by removing the reservation reqeusts that have expired and adding new ones that were requested.
At the same time as updating the most recent valid requests, we can prevent parking conflicts by keeping a count of open parking spots for each car size in each car lot when updating the circular buffer. We reject reservation requests when the count for that car size in that parking location is 0.
Trade offs/Tech choices
- We used a simple SQL server since the data is highly relational.
- No need for any load balancer as well since throughput is so low
- It's always worth it to have replication in place in case of unexpected outages. Even a single duplication greatly reduces failure chances and will not cost too much more money
- Replication and geographical sharding of the SQL server is very natural and also allows us to easily keep track of available spots
Failure scenarios/bottlenecks
Large scale events like solar eclipses or some other event may cause heavier traffic than normal. Since we cannot physically increase the size of available parking lots we will just have to reject requests if a parking location is full. Also throughput increases should not have too large of an impact if we have implemented geographical sharding since even a 10000% increase in a particular location of about 200 parking spots will only incur about a few MB of data flow.
Future improvements
We should eventually add a way to recommend close parking spots in the case a desired location is full.
We can also add analytics to understand where best to add new parking lots.