How Would You Design a Parking Lot System?
Learn how to design a parking lot system with spots, tickets, pricing strategies, and atomic allocation to prevent double-booking in interviews.
Expected Interview Answer
A parking lot system models spots, vehicles, and tickets as objects, assigns the nearest available spot matching a vehicle's size on entry, and computes a fee from the elapsed time on exit, using an in-memory or database-backed availability index to keep lookups fast.
You model the domain with a ParkingLot containing multiple Levels, each with typed Spots (motorcycle, compact, large), and Vehicles that map to a compatible spot type. On entry, an EntryGate queries an availability index (a per-type free-spot count or a bitmap per level) to find and reserve the nearest matching spot, then issues a Ticket recording the vehicle, spot, and entry time. On exit, an ExitGate reads the ticket, computes the duration, applies a PricingStrategy (flat, hourly, or tiered) to calculate the fee, processes payment, and releases the spot back to the availability index. Concurrency matters: spot reservation must be atomic (a lock or compare-and-swap on the spot record) so two cars can never be assigned the same spot, and the design should support multiple entry/exit gates operating in parallel across a large multi-level facility.
- Clear separation of concerns: allocation, ticketing, pricing
- Availability index makes spot lookup fast even in huge lots
- Strategy pattern lets pricing rules change without touching allocation logic
- Atomic spot reservation prevents double-booking under concurrency
- Scales to multiple gates and multi-level facilities
AI Mentor Explanation
A parking lot system is like a ground's ticketing office assigning seats by category — general stand, pavilion, or premium box — matching each fan's ticket type to the right section instead of letting anyone sit anywhere. The gate staff check availability per section before handing over a seat number, mark it taken the instant someone enters.
Step-by-Step Explanation
Step 1
Model the core entities
Define ParkingLot, Level, Spot (typed by size), Vehicle, and Ticket as the core domain objects.
Step 2
Build an availability index
Maintain a fast-lookup structure (per-type free counts or a bitmap) so entry gates can find a matching spot quickly.
Step 3
Handle vehicle entry atomically
Reserve the nearest compatible spot with a lock or compare-and-swap so two vehicles can never claim the same spot.
Step 4
Compute fees with a pricing strategy
Use a pluggable PricingStrategy (flat, hourly, tiered) so pricing rules change independently of allocation logic.
Step 5
Release the spot on exit
The exit gate reads the ticket, charges the computed fee, and returns the spot to the availability index.
What Interviewer Expects
- Models spots, vehicles, and tickets as distinct, well-defined classes
- Explains matching vehicle size to compatible spot types
- Uses a fast availability index rather than scanning every spot linearly
- Addresses concurrency: atomic reservation prevents double-booking
- Separates pricing logic from allocation logic (strategy pattern)
Common Mistakes
- Scanning every spot linearly to find availability instead of an index
- Ignoring concurrent entry causing two vehicles to claim the same spot
- Hardcoding pricing logic directly into the allocation code
- Forgetting to model multiple levels, gates, or vehicle size categories
Best Answer (HR Friendly)
“A parking lot system tracks which spots are free, assigns an incoming car to the right size and location of spot, issues a ticket, and calculates the fee based on how long the car stayed when it leaves. Good design keeps spot lookups fast and makes sure two cars can never be assigned the same space at once.”
Code Example
import threading
class ParkingLot:
def __init__(self, spots_by_type: dict[str, list[str]]):
self.spots_by_type = spots_by_type # e.g. {"compact": ["A1", "A2"]}
self.lock = threading.Lock()
self.occupied = set()
def park(self, vehicle_type: str) -> str | None:
with self.lock:
for spot in self.spots_by_type.get(vehicle_type, []):
if spot not in self.occupied:
self.occupied.add(spot)
return spot
return None # lot full for this vehicle type
def release(self, spot: str) -> None:
with self.lock:
self.occupied.discard(spot)Follow-up Questions
- How would you extend this design to support multiple entry and exit gates?
- How do you avoid two vehicles being assigned the same spot under concurrency?
- How would you support reserved or pre-booked parking spots?
- How would you design the pricing strategy for peak-hour surge rates?
- How would you scale the availability index across a multi-level garage?
MCQ Practice
1. Why maintain an availability index instead of scanning all spots?
A per-type index (counts or bitmaps) turns spot lookup into a fast operation rather than a linear scan over every spot.
2. Why must spot reservation be atomic?
Without an atomic reservation (lock or compare-and-swap), concurrent entries could both claim the same free spot.
3. Why separate pricing logic into its own strategy component?
A pluggable pricing strategy lets flat, hourly, or tiered rates change independently of how spots are allocated.
Flash Cards
What are the core entities in a parking lot design? — ParkingLot, Level, Spot (typed by size), Vehicle, and Ticket.
Why use an availability index? — To find a matching free spot quickly without linearly scanning every spot in a large facility.
What prevents two vehicles claiming the same spot? — Atomic reservation via a lock or compare-and-swap operation on the spot record during allocation.
What does a PricingStrategy let you do? — Swap flat, hourly, or tiered fee calculations without changing the spot allocation or ticketing logic.