System requirements

Functional:

1. Reserve a spot
2. pay for the parking spot
3. Park the car in the spot
4. Exit the spot - before/at the time
5. Cancel the spot (Basic charge)

Non-Functional:

1. Space optimisation
2. Scalability
3. Reliable (cannot assign 2 or more vehicles to the same spot)
4. Usability/Convenience
5. 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

1. Request to book a parking spot from the user
2. 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
3. lock the parkingspot status once the payment API is called, check if the amount is correctly paid and confirm the status
4. When the user cancels the parking spot status is updated
5. 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?