System requirements

Functional:

Reservation of Parking Spot: Users should be able to reserve their parking spot in advance

Payment Processing: User's need to be able to pay for their parking reservation

Early Exit: User's should be able to leave the parking before their reservation expire

Parking Expiration: User's should have additional fees added to their payment if they leave the parking after their reservation expires

No Show Policy: System need to able to handle charges if the customer doesn't show up

Non-Functional:

Consistency: Needs to prevent double-booking

Availability: System must be available for process over 99.999% of time

Scalability: The system should be able to handle pacrking reservations across different locations and handle a large number of parking lot and requets.

Capacity estimation

Given the situation where we have a parking lot with 250 available spot and we expect to have occupancy rate of 80%, and that on average each car use the parking space for at least an hour.

Additionally, the parking pass is divided accross Car types

60% --> Standard Cars

20% --> Compact Cars

20% --> Electric Cars

We need to handle 200 traffic requests at any given time. If the system is being used in 3 parking lot with the same capacity we'll account for 600 request/hour

14400 requests/day

432000 requests/month

And around 5.4 million requests/year

Each Reservation request include

Current TimeStamp ------> 13 bytes

Car Type ------> 1 byte

Reservation ID ------> 8 Byte

Reservation EndTime ------> 8 Byte

For a total of 30 bytes per request

162 MB per year

API design

The API Needs to be control user's interaction and the activity controled by the gate control service

Gate Control Service:

Operation Controlled

-Vehicle Entered(ReservationID, CarType, CurrentTimeStamp, ReservationEndTime)

/api/vehicle/start

-Vehicle Leaving(ReservationID, ReservationEndTime, CurrentTimeSTAMP)

/api/vehicle/leave

User Contol Services:

Reservation (This is endpoint allow user's to book a reservation for their parking spot)

api/reservation/booking [reservationID, LotID, CarType]

Payment (This endpoint process payment gateway for reservation booking)

api/service/payment [reservationID, reservationTime(number of hours booked), customer_name, paymentInformation]

CheckCapacity (This endpoint check the capacity of the parking lot and will be used in the reservation process)

api/service/capacity [LotID, startTime, Endtime, CarType]

CancelReservation (This endpoint will allow user's to cancel their previous registration)

api/reservation/cancel

[UserID, PaymentInformation, LotID, CarType]

Database design

the Database show incorporate these tables:

Users, Reservation, Transaction, Parking_Lot

User

UserID ---> INT [PK]

Name ---> VARCHAR

Payment Information ---> VARCHAR

Reservation

ReservationID ---> INT [PK]

UserID ---> INT [FK]

TransactionID ---> INT [FK]

ParkingID ---> INT [FK]

TimeBooked ---> INT

LotID ---> ENUM

CarType ---> ENUM

STATUS ---> ENUM

Payment_Status ---> ENUM

Parking_Lot

ParkingID ---> INT [PK]

Capacity ---> INT

Transaction

TransactionID ---> INT[PK]

UserID ---> INT[FK]

start_time

end_time

High-level design

Core Components:

1. User Interface (UI): This can be a mobile app or web application where users can iteract with the system
2. API Gateway: Serves as an entry point for client requests. It manages traffic, provides security features (like rate limiting), and directs requests to the appropriate services.
3. Reservation Service: Handles all operations related to reservations
4. Payment Processing Service: Responsible for managing payment transactions
5. Transaction Service: Manages the check-in and checkout process for vehicles
6. Database: This will be a relational database to store critical data:
7. Monitoring and Notification Service: Responsible for tracking system performance and notifying users about important events

Request flows

The sequence diagram illustrates how different services interact to process a user's request efficiently.

1. Reservation Request:
   • The User Interface (UI) initiates a reservation request by sending it to the API Gateway (A).
   • The API Gateway forwards the request to the Reservation Service (R).
   • The Reservation Service queries the Database (D) to check for availability.
   • If a spot is available, the Reservation Service creates the reservation in the database.
2. Payment Processing:
   • Once the reservation is confirmed, the Reservation Service requests payment processing from the Payment Processing Service (P).
   • Upon successful payment, the Payment Processing Service sends a confirmation back to the Reservation Service.
3. Transaction Update & Notification:
   • The Reservation Service updates the transaction status through the Transaction Service (T).
   • The Transaction Service ensures that all reservation details are stored in the Database (D).
   • The Monitoring and Notification Service (M) then sends a confirmation notification to the user.
4. Check-In Process:
   • The User (U) initiates a check-in request via the API Gateway (A).
   • The API Gateway routes the request to the Transaction Service (T), which updates the check-in status in the Database (D).
5. Check-Out & Finalization:
   • When the user decides to check out, they send a request through the UI to the API Gateway.
   • The API Gateway directs the request to the Transaction Service, which finalizes the transaction and updates the Database accordingly.

Detailed component design

The most important component of this design will be the API Gateway, the reservation system, and the transaction system.

The reservation system needs to feature an algorithm/service reponsible for finding available spot in the parking lot. It will take the time of entry and endtime to get the closest parking lot available.

For best performance, a hybrid approach can be used:

1. Use an Interval Tree to quickly check available time slots.
2. Use a Min-Heap (Priority Queue) to select the closest available spot.

Trade offs/Tech choices

Based on this system design, there's a few choices we could make.

The database system will be a relational design because it's ACID Compliant but will make complex queries slow, although considering the size of the database, sharding and indexing can be used to optimize these use cases.

We'll use a REST API for Reservation Processing, Transaction service and Payment Processing Service. For scalability, we'll use serverless compute services like AWS Lambda since it's cost efficient but will lead to some latency issues.

Failure scenarios/bottlenecks

Some of the failures or edge cases we could encounter in this system involve the Reservation and transaction services. It could lead to race condition, additionally the API Gateway is a single point of failure within this system. High write operations can slow down DB performance. Searching for the nearest parking spot across a large city can be slow

Future improvements

Load Balancing: Use NGINX, AWS ALB, or Kubernetes Ingress to distribute traffic across multiple instances.Deploy multiple instances of the API Gateway with automatic failover. Distributed Locking: Use Redis Redlock or Zookeeper to prevent double bookings. Partitioning & Sharding: Split data by time or location to distribute load. Use Read Replicas: Distribute read-heavy queries across multiple DB instances.