Designing Parking Lot (Garage) System | System Design

Designing a Parking Lot System means building a system that manages vehicle entry, parking slot allocation, ticket generation, payments, and vehicle exit. In an interview, the main focus is on efficient slot allocation, real-time availability, and handling different vehicle and parking types.

• Users should be able to enter the parking lot, get an available slot, park their vehicle, and exit after payment.
• The system should track available and occupied slots accurately and support different vehicle types such as bikes, cars, and trucks.

1. Problem Statement

We need to design a Parking Lot System where vehicles can enter, get a suitable parking spot, and exit after completing payment. The system should manage parking capacity and slot availability in real time.

• The system should automatically assign an appropriate available parking spot based on vehicle type.
• It should generate parking tickets, calculate charges, process payments, and free the parking spot when the vehicle exits.

2. System Requirements

Before designing the Parking Lot System, we need to identify its functional and non-functional requirements. These requirements define what the system should do and how well it should perform.

Functional Requirements

• The system should support different vehicle types such as bikes, cars, and trucks.
• Vehicles should be assigned a suitable available parking spot during entry.
• The system should generate a parking ticket containing entry time and slot details.
• The system should track available and occupied parking spots in real time.
• Parking charges should be calculated based on vehicle type and parking duration.
• Users should be able to make payment before exiting the parking lot.
• The parking spot should become available again after the vehicle exits.

Non-Functional Requirements

• Availability: The system should remain operational with minimal downtime.
• Scalability: It should support multiple floors, entry/exit gates, and a large number of parking spots.
• Consistency: Parking spot availability should remain accurate and prevent multiple vehicles from getting the same slot.
• Low Latency: Slot allocation and availability checks should happen quickly.
• Reliability: Tickets, payments, and parking records should not be lost.
• Security: Payment details and user-related information should be handled securely.

3. Capacity Estimation

Before designing the architecture, we estimate the expected number of parking spots, vehicles, tickets, and requests. These estimates help us choose the right database, cache, and server capacity.

Assumptions

3.1 Parking Capacity

Assume the parking lot has 10 floors with 500 spots per floor.

Total Parking Spots = 10 × 500
= 5,000 spots

The system should continuously track whether each spot is AVAILABLE, OCCUPIED, or RESERVED.

3.2 Requests Per Second

Assume around 20,000 vehicles enter and exit every day.

Entry Requests = 20,000 / 86,400
≈ 0.23 requests/second

Since each vehicle generates multiple operations such as entry, slot allocation, payment, and exit, the actual request rate will be higher.

3.3 Storage Estimation

Assume each parking record requires around 1 KB.

Daily Storage = 20,000 × 1 KB
≈ 20 MB/day

For one year:

Yearly Storage ≈ 20 MB × 365
≈ 7.3 GB/year

3.4 Peak Traffic

During office hours, events, or weekends, many vehicles may enter or exit at the same time.

The system should therefore support multiple gates and process slot allocation, ticket generation, and payments concurrently without assigning the same parking spot twice.

4. High Level Design

The High-Level Design (HLD) shows how different components of the Parking Lot System work together to manage vehicle entry, slot allocation, ticket generation, payment, and exit.

Core Components

• Client: Represents users or applications that interact with the Parking Lot System.
• Load Balancer: Distributes incoming requests across available application instances to improve scalability and availability.
• API Gateway: Acts as the single entry point for client requests and routes them to the appropriate microservice.
• Parking Service: Manages core parking operations such as vehicle entry, slot allocation, and parking status.
• Slot Management Service: Maintains parking slot information and handles slot availability and allocation.
• Ticket Service: Creates and manages parking tickets containing vehicle, slot, and entry-time information.
• Payment Service: Calculates parking charges and processes payment transactions through the external payment gateway.
• User & Billing Service: Manages user-related information and billing details.
• Notification Service: Sends parking-related notifications such as ticket creation, payment confirmation, and exit updates.
• External Gateway: Connects the system with external services such as payment providers or other third-party systems.
• Object Storage: Stores objects such as receipts, images, logs, or other large files.
• Redis Cache: Stores frequently accessed or rapidly changing data, such as parking-slot availability, to provide faster responses.
• Message Queue: Enables asynchronous communication between services and handles background tasks such as notifications and logging.
• Database: Persistently stores parking slots, vehicles, tickets, users, payments, billing information, and parking history.

Request Flow

• The vehicle enters the parking lot through the Entry Gate and sends a parking request to the API Gateway.
• The API Gateway forwards the request to the Parking Service.
• The Parking Service requests the Slot Management Service to find and allocate a suitable available parking slot.
• The Slot Management Service checks the Redis Cache for the latest slot availability and updates the slot status.
• The Slot Management Service sends the assigned slot and parking details to the Ticket Service.
• The Ticket Service generates a parking ticket containing the vehicle, assigned slot, and entry-time details. Ticket-related files can be stored in Object Storage.
• The vehicle parks in the assigned slot, and the system marks the vehicle as parked.
• When the vehicle is ready to leave, it reaches the Exit Gate and sends an exit request through the API Gateway.
• The API Gateway forwards the exit request to the Payment Service.
• The Payment Service calculates the parking fee and initiates payment through the Payment Gateway.
• After successful payment, the Slot Management Service releases the parking slot and updates its status in the Database and Redis Cache.
• The system updates the Display Board with the latest available parking slots.
• After successful payment and slot release, the vehicle is allowed to exit.

Data Flow

• Slot availability is maintained in Redis for fast allocation.
• Parking tickets, payment records, and vehicle history are stored in the Database.
• The Slot Service updates parking spot status during entry and exit.
• Payment events and system logs can be processed asynchronously through the Message Queue.
• Display boards receive updated availability whenever a parking spot changes state.

5. Technology Stack

Before designing the data model, it is helpful to identify which technologies can be used by different components of the Parking Lot System.

6. Data Model Design

The data model defines how the Parking Lot System stores and manages vehicles, parking spots, tickets, payments, and parking floors. A good schema helps maintain correct slot availability and reliable parking records.

• Identify the core entities required for vehicle entry, slot allocation, ticketing, and payment.
• Define relationships between vehicles, parking spots, tickets, and payments.
• Select the appropriate database model based on consistency, scalability, and performance requirements.

Core Entities

The Parking Lot System consists of the following core entities:

• Vehicle: Stores vehicle number, type, and owner-related information.
• ParkingSpot: Stores spot number, spot type, floor, and availability status.
• ParkingFloor: Represents a floor containing multiple parking spots.
• Ticket: Stores vehicle, assigned spot, entry time, and ticket status.
• Payment: Stores parking fee, payment method, transaction details, and payment status.
• Gate: Stores entry and exit gate information.

Database Selection

A combination of SQL and cache storage can be used depending on system requirements.

• SQL Database is suitable for vehicles, parking spots, tickets, payments, and parking history because these require structured and consistent data.
• Redis can store real-time parking spot availability for fast slot allocation.
• NoSQL Database can optionally be used for high-volume logs, analytics, and historical parking events.

7. API Design

The API design defines how different components of the Parking Lot System communicate for vehicle entry, slot allocation, ticket generation, payment, and exit.

• Design REST APIs that are simple, reliable, and easy to use.
• Use appropriate HTTP methods for parking, ticket, and payment operations.
• Secure management APIs using authentication and authorization.

Parking APIs

Ticket APIs

Vehicle APIs

Payment APIs

Sample Request

POST/api/v1/vehicles/entry

{
"vehicleNumber": "DL01AB1234",
"vehicleType": "CAR",
"entryGateId": "gate_01"
}

Sample Response

{
"ticketId": "ticket_501",
"spotId": "A-101",
"floor": 1,
"status": "PARKED",
"entryTime": "2026-09-02T10:30:45Z"
}

8. Low Level Design

The Low-Level Design (LLD) describes the internal structure of the Parking Lot System by defining the main classes, their responsibilities, and their interactions.

Core Classes

The Parking Lot System can be designed using the following core classes:

• Vehicle: Stores vehicle number, type, and basic vehicle information.
• ParkingSpot: Manages parking spot number, type, and availability status.
• ParkingFloor: Manages parking spots available on a particular floor.
• Ticket: Stores vehicle, parking spot, entry time, exit time, and ticket status.
• Payment: Manages parking fee, payment method, amount, and payment status.
• Gate: Represents entry and exit gates of the parking lot.
• ParkingService: Handles slot allocation, vehicle entry, payment verification, and vehicle exit.

SOLID Principles

The Parking Lot System follows SOLID principles to keep the design modular, maintainable, and easy to extend.

• Single Responsibility Principle (SRP): Each class handles one responsibility. For example, ParkingSpot manages slot information while Payment handles payment operations.
• Open/Closed Principle (OCP): New vehicle types, parking spot types, or pricing strategies can be added without modifying existing core logic.
• Liskov Substitution Principle (LSP): Different vehicle or payment implementations can be used through common interfaces.
• Interface Segregation Principle (ISP): Classes depend only on the methods required for their functionality.
• Dependency Inversion Principle (DIP): High-level services depend on abstractions rather than specific payment gateways or databases.

Design Patterns

9. Scalability & Performance

Scalability and performance ensure that the Parking Lot System can handle multiple floors, gates, vehicles, and parking operations while maintaining fast slot allocation and accurate availability.

• Caching: Redis stores real-time parking spot availability for fast lookup and allocation.
• Load Balancing: A Load Balancer distributes requests across multiple application servers.
• Database Replication: Read replicas improve performance and provide fault tolerance.
• Database Sharding: Parking data can be distributed based on parking lot, floor, or location.
• Horizontal Scaling: Additional Parking, Ticket, Payment, and Gate Service instances can be added as traffic increases.
• Asynchronous Processing: Kafka or RabbitMQ handles notifications, logs, payment events, and background tasks.
• Efficient Slot Allocation: In-memory indexes or Redis sets can quickly find available spots based on vehicle type.
• Distributed Locking: Redis-based locks prevent two vehicles from being assigned the same parking spot.
• Rate Limiting: Protects APIs from excessive requests and system abuse.
• Real-Time Updates: Display boards and gate systems receive immediate updates whenever a parking spot changes status.
• Multi-Parking Support: The architecture can support multiple parking lots from the same central platform.

10. Bottlenecks & Improvements

This section discusses the common challenges a Parking Lot System may face at scale and the techniques used to keep slot allocation, payments, and vehicle movement reliable.

Common Bottlenecks

• Slot Allocation Conflict: Two vehicles may try to get the same parking spot at the same time.
• Gate Traffic: A large number of vehicles entering or exiting together can create delays.
• Database Bottleneck: Frequent ticket, slot, and payment updates can overload a single database.
• Cache Inconsistency: Redis and the main database may temporarily show different parking availability.
• Payment Failure: A failed or delayed payment can block vehicle exit.
• Display Board Delay: Parking availability may not update immediately across all floors and gates.
• Service Failure: Failure of the Slot, Ticket, or Payment Service can interrupt parking operations.

Possible Improvements

• Distributed Locking: Use Redis locks or database transactions to prevent double allocation of parking spots.
• Auto Scaling: Add more service instances when traffic increases.
• Database Replication & Sharding: Distribute parking data and use replicas to improve performance and availability.
• Asynchronous Processing: Use Kafka or RabbitMQ for logs, notifications, and background events.
• Failover Mechanism: Redirect requests to healthy services if a server fails.
• Retry & Idempotency: Safely retry payment and ticket operations without creating duplicate records.
• Real-Time Updates: Push slot availability changes immediately to gates and display boards.
• Monitoring & Alerting: Monitor gate traffic, slot allocation time, payment failures, database load, and service health.