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(): Allows user to manage a reservation

Input: reservationId, updatedStartTime, updatedEndTime

Output: Updated reservation with new details


cancelReservation(): Allows user to cancel a reservation

Input: reservationId

Ouput: Returns confirmation about canceled 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

Consistency over availability: We want our system to be highly consistent to avoid double booking. A small delay in response for make reservation request is acceptable but we shouldn't let 2 users book the same spot.


Data estimation and choice of consistency, leads to use relational database over nosql database.


Relational database provides high consistency and is suitable for our data estimations and growth.


NoSQL databases are suitable for large amount of data, eventual consistency and high scalability



Failure scenarios/bottlenecks

Scalability: In case of spike in traffic, we need to consider scaling database


We can provide database sharding using lot ids


Fault Tolerance: We need to consider replicating database, create copies in different regions to avoid single point of failure



Future improvements

  • Handle concurrent requests efficiently
  • Analytics
  • Manage queues if lots are full
  • Notification service for users in case a spot becomes available
  • Support for electric vehicles and charging stations
  • Handle more types of vehicles