System requirements
Functional:
- Reserve a spot
- pay for the parking spot
- Park the car in the spot
- Exit the spot - before/at the time
- Cancel the spot (Basic charge)
Non-Functional:
- Space optimisation
- Scalability
- Reliable (cannot assign 2 or more vehicles to the same spot)
- Usability/Convenience
- Security
Capacity estimation
I assume:
- The company has operations in 10 countries.
- The company has 100 parking lots, on average, in one country.
- On average, each parking lot has a capacity of 200 cars.
- 80% of users use it for short term parking, averaging 4 hours.
- 20% of users use it for long term parking, averaging 5 days.
- Each parking lot receives 200 reservation requests per day.
Storage capacity
10*100*200*10KB parking spot info - 2GB
200 reservation requests/day
200 users/day
10*100*200*10KB reservation info / day - 2GB * 365 * 10 - 2TB for 10 years
writes per sec
10*100*200 requests/ day - 55TPS
API design
-->Book a spot
POST /reserve
Request:
{
startTime
endTime
Username
UserId
vehicleId
vehicleType
}
Response:
{
BookingId
startTime
endTime
Username
AmountToBePaid
UserId
vehicleId
vehicleType
BookingStatus - PAYMENT PENDING
}
-->Pay for the spot
POST pay/bookingId
Response:
{
BookingId
ParkingSpotNumber
startTime
endTime
Username
UserId
vehicleId
vehicleType
BookingStatus - CONFIRMED
ParkingStatus - EMPTY
}
-> Park Vehicle
POST park/bookingId
Response:
{
BookingId
ParkingSpotNumber
startTime
endTime
Username
UserId
vehicleId
vehicleType
BookingStatus - CONFIRMED
ParkingStatus - PARKED
}
--> Exit Parking
POST exit/bookingId
{
UserId
Username
startTime
endTime
}
Response:
{
BookingId
ParkingSpotNumber
startTime
endTime - updated end time
Username
UserId
vehicleId
vehicleType
BookingStatus - CONFIRMED
ParkingStatus - EMPTY
}
--> delete Booking
delete /reserve/bookingId
Response:
{
BookingId
startTime
endTime
Username
AmountToBePaid
UserId
vehicleId
vehicleType
BookingStatus -CANCELLED
}
Database design
Use a sql database , as we require the ACID properties for locking the parking spot, and transactional properties for payment systems
Regular archive of data to storage system
Current/ Todays reservation data load to cache for faster access
High-level design
Reservation System
Payment System
Cache
Request flows
- Request to book a parking spot from the user
- it flows though the web server pods , check whether the user has a validId, check if there is a spot available based on vehicleType, calculate the amount for the time and give back the response
- lock the parkingspot status once the payment API is called, check if the amount is correctly paid and confirm the status
- When the user cancels the parking spot status is updated
- when the user exits early the parking spot status is updated
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?