Requirements


Functional Requirements:

Here is how to address each specific requirement from the image:


Allow reservation of a parking spot


Action: User searches for a lot and reserves a spot for a specific timeframe.


Implementation: The Reservation Service checks the Availability Cache (Redis). If a spot is free, it creates a record in the Reservations Table with a PENDING status until payment is confirmed.


Key Detail: Use a Distributed Lock on the LotID to prevent two users from booking the last available spot at the same microsecond.


Process payment for the reservation


Action: Securely handle transactions.


Implementation: The Payment Service interacts with an external Gateway (Stripe/PayPal).


Workflow: Once the webhook from the payment provider returns Success, the reservation status is updated to CONFIRMED, and the spot is officially "locked" for that user.


Enable parking of a car in the reserved spot


Action: Mapping the digital reservation to a physical space.


Implementation: Upon Gate Check-in, the system assigns a specific Spot_ID (if spots are assigned) or simply decrements the Available_Count for that lot.


Hardware Sync: The IoT sensor at the stall detects the vehicle's presence and updates the Parking_Spot_Status to OCCUPIED.


Support early departure before reservation time expires


Action: User leaves before the scheduled end time.


Implementation: When the Gate Check-out is triggered, the system calculates the actual duration.


Business Logic: If the policy allows, the Payment Service can issue a partial refund or simply release the spot back to the "Available" pool immediately to maximize lot occupancy.


Gate check-in/out


Action: Physical entry and exit.


Implementation: * Check-in: User scans a QR code or License Plate Recognition (LPR) identifies the car. System validates the Reservation_ID.


Check-out: System verifies that the balance is zero (paid). If yes, the Gate Controller receives a signal to open.


Handle no show


Action: User reserves but never arrives.


Implementation: A Cron Job or TTL (Time-To-Live) index monitors reservations. If a user hasn't checked in within X minutes of the Start_Time, the status changes to EXPIRED/NO_SHOW.


  • Penalty: The system triggers the Payment Service to charge a "No-show fee" and releases the spot back to the public.



Non-Functional Requirements:


Define the system constraints to ensure stability and performance.

  • High Availability: The system must be operational 24/7 (99.99% uptime). A downtime means cars cannot enter/exit, leading to physical congestion.
  • Scalability: Must support thousands of parking lots and millions of daily transactions.
  • Consistency: Strong consistency is required for payments and spot allocation to prevent double-booking.
  • Low Latency: Gate entry/exit validation and spot availability checks must happen in real-time (<200ms).


API Design

MethodEndpointDescription
GET/v1/parking-lotsSearch for nearby parking lots based on GPS.
POST/v1/reservationsReserve a spot (userId, lotId, vehicleType, startTime).
POST/v1/entryTriggered by gate sensor to record check-in time.
POST/v1/exitTriggered by gate sensor to calculate fee and check-in payment.
POST/v1/paymentsProcess transaction via external providers (e.g., Stripe).




High-Level Design

A microservices architecture is preferred for independent scaling.

  1. Load Balancer / API Gateway: Handles authentication, rate limiting, and routes requests.
  2. Parking Service: Manages metadata (location, capacity, rates).
  3. Reservation Service: Handles the lifecycle of a reservation.
  4. Payment Service: Integrates with 3rd party APIs and manages the ledger.
  5. Sensor/IoT Gateway: Receives signals from physical hardware (entry/exit gates, floor sensors).
  6. Database Strategy:
    • PostgreSQL/MySQL: Primary DB for reservations and payments (ACID compliance).
    • Redis: For real-time spot availability and distributed locking to prevent race conditions.






Detailed Component Design

Handling Concurrency (The Double-Booking Problem)

When two users try to book the last spot simultaneously, we must ensure only one succeeds.

  • Solution: Use Pessimistic Locking (SELECT ... FOR UPDATE) in the RDBMS or a Distributed Lock (Redis) on the lot_id. This ensures the decrement of available spots is atomic.

Database Sharding for Scale

As the number of parking lots grows, a single DB instance becomes a bottleneck.

  • Solution: Shard the database based on Location_ID or City_ID. This keeps related data close together and allows the system to scale horizontally.