Requirements

Functional Requirements:

• Vehicle entry/exit tracking (plate, time)
• Parking spot allocation and availability tracking
• Support for different vehicle types
• Payment processing (time-based pricing)
• User accounts and subscriptions
• Reservation of parking spots
• Admin dashboard and basic reporting
• Access control (barriers, QR/plate recognition)

Low latency and real-time updates

Scalable to multiple parking lots

High availability and reliability

Secure data and payment handling

Easy to use (simple UI/UX)

Maintainable and modular system

• Integration with external services (APIs)

Non-Functional Requirements:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

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

High-Level Design

The system follows a client-server architecture. The client, which can be a mobile or web app, sends requests to a backend API gateway. The API gateway handles authentication and routes requests to different services.

The core services include a parking service to manage spot availability, a booking service for reservations, a payment service for transactions, and a user service for account management.

All services interact with a central database to store data like users, parking spots, and bookings. A cache can be used to quickly retrieve real-time availability.

Finally, the system integrates with external components such as payment providers and IoT devices like sensors or license plate recognition systems to manage physical access.

Detailed Component Design

Detailed Component Design

1. Parking Service (Core)

What it does:

Tracks real-time availability of parking spots and assigns spots.

How it works:

• Each spot has a status:
• Data stored in DB + cached in memory (e.g., Redis)
• On vehicle entry:
  • Query nearest available spot
  • Mark as occupied

Scaling:

• Cache (Redis) for fast reads (availability)
• Partition by parking lot (sharding)
• Use pub/sub or streams for real-time updates

Data Structures:

• Hash map:
• Priority queue (optional): nearest spot selection

Tradeoffs:

• Strong consistency vs speed (cache may be slightly stale)
• Simpler design vs optimal spot assignment

2. Booking Service

What it does:

Handles reservations of parking spots in advance.

How it works:

• User requests reservation → system locks a spot
• Uses TTL (time-to-live) for temporary holds
• Prevents double booking via atomic operations

Scaling:

• Distributed locking (e.g., Redis locks)
• Horizontal scaling with stateless services

Algorithms:

• Optimistic locking (versioning) OR
• First-come-first-serve with atomic check-and-set

Tradeoffs:

• Overbooking risk vs strict locking (performance impact)
• Holding spots too long reduces utilization

3. Payment Service

What it does:

Calculates fees and processes payments.

How it works:

• Computes price based on entry/exit time
• Calls external payment gateway
• Stores transaction results

Scaling:

• Async processing with queues (e.g., Kafka)
• Retry mechanism for failed payments

Capacity Considerations:

• Peak load during exit hours
• Design for high write throughput

Tradeoffs:

• Sync vs async payments (UX vs reliability)
• External dependency latency