Loading...
List functional requirements for the system (Ask the chatbot for hints if stuck.)...
x floors
y number of spots for each floor
disabled parking near elevators
2elevators on both sides of the building
Stairs entry/exit on each floor near the elevator
payment machine near the elevator
automated ticket at entry
scan a receipt or payment option at the exit
EV chargers are available on each floor
Booking System
Online booking - putting vehicle size and start and end time
Keeping track of empty spots available for each size
SpotManagement
Max number of parking spots based on size, small medium, and big cars
Payment system
Confirmation email with type of spot
Change request
List non-functional requirements for the system...
Scalable for multi parking lots, based on location
can take simultaneous requests
Eventual consistency
Available
Partial tolerance
Estimate the scale of the system you are going to design...
90 spots * 500 bytes = 45 MB
Define what APIs are expected from the system...
Post to book parking { size, from, to, car_lic# } return confirmation #
if payment is successful else return error
Put to update { from_time, to_time, car_lice#, booking_id}
Put to extend { to_time, car_lic#, booking_id}
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...
User
id userid name balance car_lic
Transaction
id booking_id booking_date parking_from parking_to size userid car_lic amout_due amount_charged
open_spots
id spot_id size
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...
flowDiagram LR
A[client] -->|request|B[API agetway]
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...
A[user] -->|request to book|[ server] - ->|check availability|[database]
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...
API gateway:
will do Authentication,
Rate limiting using leaky token bucket
and load balancing
Booking Service:
checks spot based on requested time, size, books it if payment is successful, returns confirmation and updates db via space manager service
Space manager Service:
keeps track of number of open spots based on size, special needs (handicap)
Explain any trade offs you have made and why you made certain tech choices...
SQL vs noSQL
SQL should work fine here, we know db wont change much, easier to query joining with payments
Try to discuss as many failure scenarios/bottlenecks as possible.
If the booking service or space manager is down, replicas will be good, queue between the booking service and space manager will help in case the space manager is down
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
Add analytics > what time its most and least busy
add Monitoring and alerting