System requirements


Functional:

  1. Reserve parking space
  2. Manage reservation
  3. Make payment
  4. Accommodate types of vehicles
  5. Support for short and long term parking


Non-Functional:

  1. Consistency over availability: To avoid double booking
  2. Security: For payment service
  3. Scalability: Handle increase in traffic




Capacity estimation

Total no of parking lots: 1000

Capacity of each parking lot: 200

200K daily new reservations


Total data size for each reservation = ~200B

Data stored everyday = 200B * 200K = 40MB

Data store in 2 yrs = 40MB * 365 * 2 * 1.5(considering growth) = 43GB


Estimation leads us to relational database like SQL or PostgreSQL.


RDBMS provides strong consistency which is required for the system


API design

checkAvailability(): Checks whether a given parking spot is available for reservation

Input: lotId, reservationStartTime, reservationEndTime, vehicleType

Output: status


reserveSpot(): Reserves a spot for the user

Input: userId, spotId, reservationStartTime, reservationEndTime, vehicleType

Output: reservationId


vehicleEntry(): Tracks entry of vehicles

Input: reservationId, timestamp of entry


vehicleExit(): Tracks exit of vehicles

Input: reservationId, timestamp of exit


payment(): Allows user to make payment. Integrated with 3rd party


manageReservation(): Allow user to manage/delete a reservation


Database design

ReservationDetails:

  • reservationID(PK)
  • LotID(FK)
  • SpotID(FK)
  • userID(FK)
  • vehicleType
  • reservationStartType
  • reservationEndType


User:

  • UserID(PK)


Spot:

  • spotID(PK)
  • lotID(FK)
  • status


Lot:

  • lotID(PK)
  • numSpots


VehicleType:

  • vehicleID(PK)
  • userID(FK)
  • vehicleType


High-level design

Client: Sends request for reservation

Reservation Service: Handles reservation requests

Payment Service: Handles payment for reservation

Stripe: 3rd party payment integration

MySQL: Relational database for consistency



Request flows

Check availability:

  • Request to check if spot is available
  • Reservation service checks from database if a spot is available for given vehicle type
  • Return spot availability


Reserve spot:

  • Client sends request to reserve a spot
  • Reservation service updates database with details
  • Returns confirmation if spot was reserved


Make payment:

  • Payment request is sent to payment service which in turn sends details to 3rd party payment integration
  • Payment confirmation is sent to user


Manage reservation:

  • Client sends request to update/cancel reservation
  • Reservation service handles modification and updates database accordingly
  • Reservation service returns appropriate result


Detailed component design

API gateway: Handles API routing to different services


We can have multiple instances of servers across different zones to handle client requests from different regions.


We can also shard database based on lot ids. This helps handle increased load in case of events or high traffic


Trade offs/Tech choices

Choice of relational database over nosql database: We choose consistency over availability to avoid double booking.




Failure scenarios/bottlenecks






Future improvements