System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
- Reserve a space for an allotted time, pay through a third party application and get a ticket/receipt for payment
- Look up available parking spots
- Cancel an existing reservation
Non-Functional:
List non-functional requirements for the system...
- System must be highly consistent so no collision occurs and two spaces are not reserved at the same time, can sacrifice some latency for this
- Should be able to connect with third party applications well; i.e. Stripe for payment, potential Calendar application integration
- Be regionally available for support for 10 different countries
Capacity estimation
Estimate the scale of the system you are going to design...
- 200,000 write requests per day for all parking lots with around 2.3 write requests per second. Assume five times the amount of read requests for about 10 reads per second or 1,000,000 reads a day between all parking lots
- Estimate around 120 bytes for each entry between (name,parking_space,times_start,time_end). 120 bytes x 200,000 writes/day x 365 days x 5 years = 43.8 GB of storage within 5 years. Can use 100 GB of storage
API design
Define what APIs are expected from the system...
Public Endpoints
/reserve
POST Request - User selects allotted space and reserves it before proceeding to third party payment (Stripe). Handles functional requirements of reserving and looking up available spaces.
Params:
(int reservation_id,int parking_space_id,str name, str parking_space)
/payment
Params:
int reservation_id
(Handled by third party - Stripe)
/cancel
Params:
int reservation_id
Internal Endpoints
/calculateFreeSpots
Used to calculate how many free spaces we might have available in a parking lot to display on our web app
Params:
int parking_lot_id
Database design
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
- Use relational database (Postgres), not a high amount of data to justify excessive scaling for database through NoSQL
- Lots of relational transformations possible, i.e. joins based on parking_lot_id to find total number of available parking spaces in a particular country/city
- Relational databases are good for avoiding collision too due to ACID properties
Tables:
Parking_Lot_Tbl
Schema
parking_space_id (int: Primary Key - Unique)
parking_lot_id (int)
space_type: (varchar)
address: (varchar)
city: (varchar)
country: (varchar)
available: (boolean)
Transaction_Tbl
Schema
transaction_id (int: Primary Key - Unique)
name: (varchar)
parking_space_id: (int)
space_type: (varchar)
date: (datetime)
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...
- Utilize CDN (Pull-based since content is static - AWS CloudFront) due to 100 parking lots in 10 different countries, differences in currency and price. CDN also helps in showing spaces only relevant to client i.e. within the same city
- Load balancer for distributed system (AWS Network Load Balancer since high amount of reads), with servers in multiple availability zones, can use AWS EC2 servers set up across multiple regions/Availability zones
- Multiple SQL database replicas to support availability across multiple countries with good support for reads. Synchronous replication across databases to ensure consistency at the cost of slight latency to ensure no collision is happening for the same parking spots.
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 requests server through GET and POST requests to look up and reserve a space in a specified parking lot. CDN controls which parking lots show up to client
- Database handles storage and shows available spaces along with the types
Detailed component design
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
- CDN serves to show most readily available parking lots to client based on location
- Load Balancer (AWS Network Load Balancer - due to multiple reads) - can utilize Geolocation based load balancing to match clients closer to their parking lots. Could also include some weighted policy to the load balancer for high volume areas (NYC).
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
- Have added some latency from the usage of synchronous replication for database but allows for more consistency and prevents collision on same parking spaces.
- Added latency from cross regional transactions with the presence of parking lots in 10 different countries.
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
- Highly traffic areas could be subject to more usage depending on different times of day i.e. NYC with a big concert, system needs to be able to scale during these high traffic changes
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
- Incorporate license plate usage as opposed to numbered spaces within parking lot, would require more changes in CDN based on license plate changes between countries