Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

- 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:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• Scalable, Available, Reliable
• Concurrency management (for race conditions while booking an available parking spot)
• User friendly
• Good consistency (so that when a parking spot is made free or taken, it reflects fast)
• Extensibility (to extend the parking spaces to different types of vehicles)

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

Back of the envelope estimations:

DAU —> 2M

Reads / checking for available spots —> 23/s avg, peak ~115/s

Writes / reservations —> 2.3/s avg, peak ~12/s

QPS —> Read + Write —> 25/s avg, peak ~125/s

Read:Write —> 10:1

Data storage —> user data + parking lots data + reservations data for lets say 5 yrs —> (5M * 1KB) + (500K * 1KB) + (200K * 365 * 5 * 1KB) ~ 6GB

CAP theorem —> System should be CP for writes and AP for reads. We can use an RDBMS like PostgreSQL with strict ACID transactions and distributed locking. If a network partition occurs, we will sacrifice availability and reject incoming reservations for affected zones to absolutely guarantee that we never double-book a physical asset.

Latency —>

i. Read: User —> API gateway/LB —> server —> cache or then DB —> back to client = (30-80ms) + (5-15ms) + (2-5ms) + (20-60ms) + (30-80ms) = 100-150ms

ii. Write: User —> API gateway/LB —> server —> DB (example - acquire lock on parking spot) —> Payment gateway (can be third party, so can take 400-1000ms) —> DB (status update) —> back to user = 700-1500ms

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...

i. /api/v1/parking-spot?city=delhi GET

ii. /api/v1/parking-spot?lat=1&long=2 GET

iii. /api/v1/parking-spot?loc=noida-sec-100 GET

Response for i, ii, iii:

{ "total_results": 2, "parking_spots": [ { "id": "spot_abc123", "parking_lot_id": "lot_7788", "parking_lot_name": "Downtown Central Garage", "vehicle_type": "SUV", "approx_rate": 15.50, "status": "AVAILABLE", "image_url": "https://parkingsystem.com" }, { "id": "spot_xyz789", "parking_lot_id": "lot_7788", "parking_lot_name": "Downtown Central Garage", "vehicle_type": "SEDAN", "approx_rate": 12.00, "status": "OCCUPIED", "image_url": "https://parkingsystem.com" } ] }

iv. /api/v1/parking-spot/{:id}/ GET

Response will be similar to above

v. /api/v1/reservation POST

JSON body:

{ "user_id": "user_usr_99824", "vehicle_id": "veh_vhc_44102", "parking_spot_id": "spot_abc123", "start_date": "2026-10-26T18:00:00Z", "duration_minutes": 120 }

Response:

{

"status": "SUCCESS",

"reservation_id": "res_rsv_773910",

"payment_id": "pay_chg_884021"

}

vi. /api/v1/reservation/{:id}/checkin POST

vii. /api/v1/reservation/{:id}checkout POST

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.

We mainly use Microservices architecture to solve this problem. Each service has its own DB and cache for separation of functions and concerns.

i. ParkingLotService: This is the central service which is responsible for the orchestration of all the flows and services from searching for available parking spots to booking the spot.

ii. RateService: This service is solely responsible for providing the rate of a particular parking spot according to varying factors.

iii. PaymentService: This service is for completing the payment during making a reservation.

iv. ReservationService: During reservation process and also during other flows such as check-in and cancellation, this service will be involved as it will be updating the DB for the reservation and its details and status.

v. ParkingLotSearchService: This service will be fetching list of available parking spots according to any search criteria provided, it could be user's current location or city searched by them.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Choice of DB - SQL DB like PostgreSQL or MySQL - Reason - Read intensive, structured or static schema and not flexible schema, ACID properties, locks and DB constraints needed for consistency during concurrency.

Tables:

• User: id, name, email, phone, address
• VehicleType: Car, Truck, Bicycle, Tempo, Van
• Vehicle: id, user_id, type, lisence_plate_no
• City: id, geohash, name, country_name, pin
• ParkingLot: id, name, city_id, parking_spot_list
• ParkingSpot: id, vehicle_type, vehicle, status, parking_lot_id
• PaymentMethod: Credit, Debit, UPI, Cash
• Payment: id, reservation_id, status, payment_method
• Reservation: id, user_id, created_at, status, duration, start_date, payment_id, vehicle_id, parking_spot_id

Relationships:

• User:Vehicle = 1:N
• ParkingLot:ParkingSpot = 1:N
• City:ParkingLot = 1:N
• User:Reservation = 1:N
• Reservation:ParkingSpot = 1:1
• Reservation:Payment = 1:1

Indexes:

• ParkingLot and City tables can be indexed on name
• ParkingLot can be indexed on city_id
• Vehicle table can be indexed on user_id
• ParkingSpot table can be indexed on parking_lot_id

Other techniques - sharding (on basis of user id or parking_lot_id), replication for redundancy and query optimization for fast DB

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.

Different flows of the application:

1. User fetching all parking spots near them: This request will be sent to ParkingLotService. ParkingLotService DB will have all details related to each and every parking spot and user too. Each parking spot has its location/city and its parking spot id. To determine id's of nearest parking spots, the ParkingLotSearchService will be called with the required search criteria. It could be user's current location in the form of lat long or a location searched by customer. Once we have the required parking lot id's, RateService may be queried for the approximate rates to be displayed. All these details will be sent to client.
2. User clicks reserve on the preferred parking spot: First ParkingLotService will acquire a lock on the parking lot or mark it as On hold, then RateService will be called to determine the exact price based on User details, parking spot details and current time and date. Now ReservationService will be called for creating Reservation details and its payment will be marked as Pending. Now ParkingLotService will call PaymentService with the rate and Reservation details. This service will redirect user to payment page and return success or failure back to ParkingLotService. After that Parking lot to be marked as reserved and payment status as success or failure and notify the customer that reservation is done.
3. Check in / check out: When check in and check out are selected, this request goes to ParkingLotService and it updates the status of the parking lot as Checked in or available, and also called ReservationService to update the reservation status in its DB as Checked in or checked out.