System requirements
Functional:
- Allow user to book a space in the parking lot based on their chosen car type, date, time
- Pre-payment functionality
- Lot is open 24/7, can be booked in 1 hour slots
- Discounts of 20% apply if parked for longer term
Non-Functional:
- Consistency is required to ensure the system does not double book any parking slots
Capacity estimation
- Assume 1000 parking spaces in the lot, of which 800 are for normal cars and 150 for oversized cars, and 50 accessibility spots
API design
- POST /api/booking/ request with users desired entry/exit datetime, car size, returns availability and price
- GET /api/booking/ request bookings to show all bookings, /api/booking/<int>/ to lookup a specific booking
Database design
- User table with id, address/phone info etc
- Parking slots table with each space and its associated type (normal, oversized, accessibility) and price per hour
- Booking table with user_id FK, parking_slot FK, payment info
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...
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
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...
Trade offs/Tech choices
- Using a relational database as we need consistency plus the amount of data isn't large (1000 spots * 24 slots per day * 365 is 8.8m rows which is reasonable)
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?