Requirements
Functional Requirements:
- Allow reservation of a parking spot.
- Process payment for the reservation.
- Enable parking of a car in the reserved spot.
- Support early departure before reservation time expires.
- Gate check-in/out.
- Handle no show.
Non-Functional Requirements:
- Support between 1000 to 10000 parking lots
- Strong consistency -Double booking not allowed
- The system shall ensure high availability with an uptime target of 99.9% or greater. This will be achieved through the use of redundant services across multiple availability zones, load balancing to distribute traffic, and automated failover mechanisms to maintain service continuity during component failures. Additionally, the system should be designed to handle peak loads efficiently, ensuring that users can reserve parking spots and process payments without interruption.
Capacity Estimation
- Operate across 10 countries
- 100 parking lots per country
- Each parking lot capacity is about 200
- Short term parking(Upto 4 hours) - 80 percent of requests
- long term parking (Upto 1 week)- 20 percent.
- 200 requests per day on average per parking spot
API Design
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
- check_parking_spot(parking_lot_id, lot_type, duration)
Checks for availability of a parking spot. lot _type refers to parking lot type for small/large vehicles. Return a boolean true/false if lot is available
GET api/parking/{parking-lot-id}
JSON payload - {
"lot-type": type,
"duration": time
}
- reserve_parking_spot(parking_lot_id, user_id, lot_type,vehicle_id, duration)
Reserves a spot in a parking lot for a particular user and vehicle.
Returns reservation _id
- check_in(parking_lot_id, reservation_id, checkin_time)
Check in for a parking at a slot. Validates if the check in is valid. Returns true for a valid checkin else false.
- check_out(parking_lot_id, reservation_id, check_out_time)
check out from a parking slot
POST request POST /api/parking/{parking-lot-id}/checkout
JSON payload - {
"reservation_id": rid,
"checkout_time": time
}
Response - Success 200 OK
High-Level Design
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
- API gateway - Entrypoint. Implements a rate limiter to handle traffic spikes
- ParkingReservationService - Check availability, Handle reservations , check in and checkout
- Payment Service - Handles payment request for parking lot reservations
- NoShow Handler Service- Keeps track of no show reservations and updates the status accordingly. It runs periodically.
Database Design
- Reservations - reservation_id, lot_id, user_id, vehicle_id,
- User- user_id, Name, Location
- ParkingLot- lot_id, Lot_name, location, total_capacity,cat1_capacity, cat2_capcity
- Vehicle- vehicle_id, name, vehicle_type
User flow-
- create_reservation- Request goes to API gateway from the client. It is forwarded to the Reservation service which then validates the details and invokes the payment service to make the payment. This service stores the details of the transaction into the db.
- Checkin/check out flow- For every check in/ check out , the request is sent from the gate devices in the parking lot to the API gateway. This is then forwarded to the reservation service to update the reservation status as checked in. ON check out, a further check is done to check if any amount is due and the payment service is invoked accordingly
Detailed Component Design
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
Database- the data for the parking lot details is relatively stable , with no frequent changes.
Given that we want strong consistency, we can go with SQL databases like postgreSQL.
Database size - 10* 100 * 200 *200 =-40,000,000 entries at max per day for reservations. 1kb per entry - 40 gb of data
Database can be partitioned by parking lot ID. This is beneficial because all the tables (e.g. Reservation, Spots) for a given parking lot would always be on one database node, avoiding scatter-gatherer pattern. The database should also have read replicas to enhance read performance and fault tolerance.
For Fault tolerance , we can use read replicas of the database