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

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.