Design a Parking Lot

The classic object-modeling round. How to scope it, the entities and their relationships, where Strategy fits for spot assignment, and the extensibility follow-ups.

LLDOODclass-design

How to run an OOD question

It's not about UML perfection — it's about clean responsibilities and extensibility. Steps: clarify scope → identify entities (nouns) → assign responsibilities (verbs) → relationships → call out where behavior varies (Strategy) → walk a scenario.

Clarify first: multiple levels? vehicle sizes (motorcycle/car/bus)? pricing? payment? Pin scope: "single lot, multiple levels, three spot sizes, hourly pricing, ignore payments — OK?"

Entities & relationships

  • ParkingLot is the facade: parkVehicle / unpark. It owns levels and issues tickets.
  • Level owns spots and answers findSpot(vehicle).
  • ParkingSpot has a size and canFit(vehicle); subclasses or a size enum (prefer the enum + canFit over a deep spot hierarchy).
  • Vehicle hierarchy (Car/Motorcycle/Bus) carries size.
  • Ticket records spot + entry time for fee calculation.

Where the patterns live

  • Strategy — spot assignment. "nearest", "first-available", "fit smallest spot" are interchangeable SpotAssignmentStrategy implementations injected into Level. New policy = new class, no edits (Open/Closed).
  • Strategy — pricing. FeeStrategy (flat, hourly, tiered) computed from the ticket.
  • Singleton (maybe). One ParkingLot instance — but inject it rather than reaching for a global.
Prefer an enum + capability over a class explosion

Modeling every spot/vehicle combination as a subclass blows up fast. A size enum plus spot.canFit(vehicle) keeps it small and handles "a car can use a large spot if no compact is free" without new types.

Here's that spot-assignment strategy running. A motorcycle fits anywhere; a car needs a compact-or-larger spot; a large vehicle needs a large spot. Watch the scan reject spots that are taken or too small, then take the first that fits — swap the operations to test "two cars, one compact left".

Parking lot — nearest-fit spot assignmenttime O(spots) per parkspace O(spots)
entrance →
moto·spot 0
moto·spot 1
compact·spot 2
compact·spot 3
compact·spot 4
large·spot 5
large·spot 6

dashed = free · a vehicle takes the nearest spot ranked its size or larger

1/287 spots: two motorcycle (M), three compact (C), two large (L). A vehicle parks in the nearest spot it fits — bigger spots accept smaller vehicles, never the reverse.

free = 7

Think it through like the interview

Before reading further, try to run the method yourself — this widget walks the exact five moves, one at a time:

Think it through: Design a Parking LotLLD Classic0/5 stages

PROBLEMDesign the classes for a parking lot: vehicles arrive, get a spot that fits, receive a ticket, and pay on exit. You have ~35 minutes and a whiteboard.

  1. 1

    Clarify scope

    “What would change my design the most? Ask THOSE questions first.”

  2. 2

    Nouns → entities

    “Read the problem statement back. Which nouns survive as classes?”

    unlocks after the stage above
  3. 3

    Verbs → responsibilities

    “Who owns parkVehicle? Who owns findSpot? Why not all on ParkingLot?”

    unlocks after the stage above
  4. 4

    Spot what varies → patterns

    “Which decisions might change next month without the structure changing?”

    unlocks after the stage above
  5. 5

    Walk a scenario + break it

    “Narrate 'a car arrives'. Then: two cars, one spot left. What breaks?”

    unlocks after the stage above

Walk a scenario + concurrency

"A car arrives": ParkingLot.parkVehicle(car) → ask each Level for a spot via its assignment strategy → mark spot occupied → issue Ticket. Concurrency follow-up: two cars racing for the last spot is the same race as a balance double-spend — guard spot acquisition atomically (compare-and-set on the spot's state, or a lock per level) so a spot is never double-assigned.

Practice — level up

A parking lot is an allocation problem: hand out a limited resource, take it back, and enforce "one holder at a time". These drills are the same shape.

Practice ladder: Resource allocation0/4 solved

Climb in order — every rung assumes the one above it. Solve on LeetCode, then tick it here; progress is saved on this device.

Warm-up — count what's free

Allocation with nothing but counters.
  1. Design Parking SystemEasy

    Per-size counters — the simplest spot allocation.

Core — allocate & release specific slots

Now identity matters: which spot, given back.
  1. Seat Reservation ManagerMedium

    Reserve / unreserve numbered slots — parking spots by another name.

  2. Design Circular QueueMedium

    Fixed capacity with free/occupied bookkeeping and wrap-around.

Stretch — paired entry/exit + fees

Ticket on the way in, charge on the way out.
  1. Design Underground SystemMedium

    Check-in/check-out pairs and aggregate on exit — the ticket-and-fee half of the lot.