System requirements
Functional:
- User can reserve a parking lot
- User can pay for a reservation
- User can park car in the park lot
Non-Functional:
- Scalability: the system operates for multiple countries
- Reliability: the system should be 99.9% available for user to make reservation
- Security: the system should protect cars to be broken or stolen
- Consistency: once user make the reservation, the parking lot is available to user and unavailable for others.
Capacity estimation
- the system has parking lots in 10 countries
- In each country, there are 100 parking lots
- On average, each parking lot can park 200 cars
- On average, 80% users park for 4 hours
- On average, 20% users park for 5 days
- Each parking lot receives 200 reservation request each day
Estimation
- total parking lots: 100 * 10 = 1000
- The system receive : 1000 * 200 = 200000 reservation each day
- Each reservation need roughly 128 bytes
- reservation ID: 8 byte
- user ID: 8 bytes
- car type: 1 byte
- start time: 8 bytes
- end time: 8 bytes
- Each day, new data is 128 * 200000 = 25.6M
- In two years, the data will add up to 25.6 * 365 * 200K * 1.5 =27.6P
API design
Define what APIs are expected from the system...
- List parking lots
- Input: city
- Output: park lots in the city
- List available parking spaces in a parking lot
- Input: park lot ID
- Output: parking spaces with status
- Reserve a parking space
- Input: parking lot ID and space ID
- Output: success or failure of the reservation
- Complete a reservation:
- Input: Parking lot ID and space ID
- Output: success of failure of the operation. Fee to be paid
- Cancel a reservation
- Input: Parking lot ID and space ID
- Output: success/failure of the operation. Fee involved
- Car checkin:
- Input: car ID, parking lot ID, space ID. time
- Output: success/failure of the operation.
- Car checkout:
- Input: car ID, parking lot ID, space ID, time
- Output: success/failure of the operation
Database design
- Reservation table
- Reservation_id
- user_id
- start_date
- end_date
- Slot table
- slot_id
- lot_id
- location
- vehicle_type
- status
- ParkLot table
- lot_id
- capacity
- city
- address
- Vehicle table
- vehicle_id
- vehicle_type
- contact_id
- Contact table
- user_id
- user_name
- user_email
- User table
- user_id
- user_name
- user_email
- Transaction table
- transaction_id
- user_id
- vehicle_id
- start_date
- end_date
- amount
- status
High-level design
- User
- Parking lot entrance system
- API gateway
- reservation service
- payment service
- transaction service
- database
- cache
Request flows
- User make reservation:
- User list parking lots in the city
- User view available of spaces in a parking lot
- User make reservation
- The system save the reservation information
- User is confirmed about reservation
- Char check-in
- Car arrives at parking lot
- The parking lot entrance system send information about user, car ID
- The system confirm the validity of reservation and allow the car to enter. Start counting fee.
- The parking lot entrance system allow the car to enter.
- The monitor of the slot detect car coming and send car ID
- The system confirm the car parked is the same as what is reserved and updating the resevation and trnasaction information
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
Explain any trade offs you have made and why you made certain tech choices...
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?