Design a Parking Lot

Intermediate · 28 min read · Low-Level Design, Case Studies: Core

Spots, vehicles, tickets, pricing strategies and concurrent allocation.

The parking lot is the most frequently asked LLD problem. It's small enough to finish, yet it tests modelling, the Strategy pattern, extensibility (new vehicle types, pricing rules) and — the part most candidates miss — concurrency at entry gates.

What the interviewer expects

The full design in this lesson is longer than anything you'd write in one round. It's there so you understand the edge cases and can answer follow-up questions. In the round itself, aim for this:

1. Clarify requirements

Functional use cases: park a vehicle (get a ticket), unpark (compute fee, pay, free the spot), view availability.

2. Entities and relationships

3. Class diagram

4. Implementation

A lock per floor keeps contention low (gates allocating on different floors don't block each other) while keeping the check-then-act on spots atomic.

5. Concurrency analysis

Payment happens outside locks — never hold a lock across a slow external call.

6. Patterns used

A Singleton ParkingLot is often suggested; prefer creating one ParkingService at startup and injecting it — same single instance, testable.

7. Extensions interviewers ask for

Interview questions

• How do you prevent two entry gates from assigning the same spot?
• How would you add a new vehicle type, say an electric scooter?
• Why compute the fee before freeing the spot, and what if payment fails?

Further reading

Key takeaways

• Model with enums for data-only variants and interfaces for behaviour that varies (pricing, allocation).
• ParkingService is a thin façade; floors own their spots and allocate atomically.
• Lock per floor (or CAS per spot) prevents double assignment; keep payments outside locks.
• Inject Clock, repositories and strategies for testability and extensibility.

Previous: Machine-Coding Walkthrough: Snake & Ladder · Next: Design a Vending Machine