Requirements

Functional Requirements:

• The system should be able to track empty/occupied spaces
• The system should be able to reserve a parking spot for vehicle
• The system should be able to track and store payment details
• The database should be able to store details of the vehicles parked including vechicle id, owner name, check in and check out date and timings.

Non-Functional Requirements:

• The system should be consistent as in no user should be able to book same spot
• The system should be available
• We can compromise over scalability since we won't be dealing with millions of vehicles at a time.
• The system should endure low latency

Capacity Estimation

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

API Design

1. Get All Spots:
   • Endpoint: GET api/v1/spots
   • Description: Get the list of all the parking spots with their availability
   • Query Parameters: Status - AVAILABLE, RESERVED and OCCUPIED
2. Reserve a spot:
   • Endpoint: POST api/v1/reservation
   • Description: Reserves a spot for a vehicle
3. Get Reservation Details:
   • Endpoint: GET api/v1/reservation_details
   • Description: Get reservation details for a particular parking spot
4. Check Out Vehicle:
   • Endpoint: PUT /api/v1/reservations/{reservation_id}/checkout
5. Process Payments:
   • Endpoint: POST/v1/payment
6. Get Payment Details:
   • Endpoint: GET/v1/payment/{payment_id}

High-Level Design

• The API Gateway rate-limits and routes traffic.
• The Reservation Service handles search, capacity, and booking.
• The Payment Service verifies payment with the PSP and updates reservation state via webhook.
• Redis caches capacity and prices — advisory only; the RDBMS stays the source of truth.
• Gate devices call check-in/check-out.
• Background jobs expire unpaid holds.
• User searches → Reservation Service checks cached capacity → user picks a spot → spot is held (10-min expiry) → Payment Service charges via PSP → webhook finalizes the reservation → gate check-in on arrival.
• The lock/DB commit decides the winner on same-spot conflicts; cache staleness can't double-book.

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

Detailed Component Design

• API Gateway/ Load Balancer - Handles routing, rate limitation and SSL termination. Direct incoming REST APIs to internal backend services
• Reservation and Spot Service - Manages parking spot states. Handles spot-discovery, booking, vehicle check-in and check-out workflows. Enforces business logic to stop race condition during spot assignment
• Payment Service - Handles billing calculation upon check-out based on duration
• In Memory Distributed Lock - Guarantees that concurrent requests for the exact same spot ID are serialized before hitting the database, maintaining submillion coordination speed
• Relationship Database - Provides ACID compliance to strictly enforce no double booking at data level.