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

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

Future improvements

• Handle concurrent requests efficiently
• Analytics
• Manage queues if lots are full
• Notification service for users in case a spot becomes available