Design Parking Lot
Last Updated: January 22, 2026
What is Parking Lot?
A parking lot is a designated area where vehicles can be parked temporarily, either in public or private spaces.
Loading simulation...
It may consist of multiple floors, and each floor contains a fixed number of parking spots. These spots are often categorized by vehicle size such as small, compact, or large.
When a vehicle enters the parking lot, a parking ticket is issued to record the entry time. Upon exiting, the vehicle owner pays the parking fee.
In this chapter, we will explore the low-level design of a parking lot system in detail.
Let's start by clarifying the requirements:
1. Clarifying Requirements
Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions, clarify ambiguities, and define the system's scope more precisely.
Here is an example of how a discussion between the candidate and the interviewer might unfold:
Candidate: Is the parking lot a single-level or multi-level structure?
Interviewer: Let’s assume it is a multi-level parking lot. Each level can have a different number of parking spots.
Candidate: Do we need to support different types of vehicles, such as bikes, cars, and trucks?
Interviewer: Yes, we’ll support at least these three types: bikes, cars, and trucks.
Candidate: Should the system enforce compatibility between vehicle types and parking slot sizes?
Interviewer: Yes, each vehicle must be assigned to a compatible spot type based on its size.
Candidate: Should parking spot assignment be automatic, or should users be able to choose a spot manually?
Interviewer: To keep things simple, let’s use automatic allocation based on availability.
Candidate: Should the system support querying and displaying for open slots?
Interviewer: Yes, users should be able to view open spots based on their vehicle size.
Candidate: Should parking spot IDs follow a specific sequence, like B1, B2, etc., or can they be random?
Interviewer: In real-world systems they are usually ordered, but for this problem, you can assign random IDs.
Candidate: Do we need to track entry and exit times for each vehicle to calculate parking fees, or will it be a flat-rate system?
Interviewer: We should track both entry and exit times. Parking fees will be calculated based on the duration of stay.
Candidate: Do we need to take input from the user, or can we hardcode a sequence of parking requests for this design?
Interview: You can hardcode the sequence for this design. No need for user input handling.
Parking Rules
Since the system must enforce compatibility between vehicle types and parking spot sizes, it’s important to clearly define the parking rules.
In real-world scenarios, the following constraints typically apply:
- Bikes can be parked only in small parking spots
- Cars can be parked in compact or large spots
- Trucks can be parked only in large spots
These rules ensure optimal utilization of space and prevent oversized vehicles from occupying undersized spots.
After gathering the details, we can summarize the key system requirements.
1.1 Functional Requirements
- Support multiple parking floors, each with a configurable number of parking spots.
- Support multiple vehicle types, including bikes, cars, and trucks
- Classify parking spots by size (e.g., Small, Medium, Large) and match them with appropriate vehicle types
- Automatically assign parking spots based on availability
- Issue a parking ticket upon vehicle entry and track entry and exit times
- Calculate parking fees based on duration of stay and support different pricing strategies, such as flat-rate or vehicle-type-based pricing.
- Support querying and displaying real-time availability of parking spots, grouped by floor and spot size.
- Parking requests can be hardcoded in a driver/demo class for simulation purpose.
1.2 Non-Functional Requirements
- The design should follow object-oriented principles with clear separation of concerns
- The system should handle concurrent entry/exit events without race conditions
- The system should be modular and extensible to support future enhancements
- The code should be thread-safe for concurrent access
- The components should be testable in isolation
Now that we understand what we're building, let's identify the building blocks of our system.