Design a Parking Lot (Low-Level Design / OOD)

🟠 Low-Level Design · Case Study · the classic machine-coding round

"Design a parking lot" is the most common low-level design / machine-coding question there is — the LLD equivalent of the URL shortener. It's perfect for testing OOD because it has clear objects, natural relationships, and just enough variation (vehicle types, spot types, pricing) to reward good design. Let's walk it the way you would on a whiteboard: requirements → classes → relationships → the design decisions that impress.

Step 1 — Clarify requirements

Always scope first. A reasonable set:

• Functional: a lot with multiple levels; different spot types (motorcycle, compact, large); different vehicle types (bike, car, truck); park a vehicle in a suitable free spot and issue a ticket; unpark and pay based on duration.
• Non-functional: find a spot fast, handle a full lot gracefully, be extensible (new vehicle/spot types, new pricing).

Step 2 — Find the classes (nouns → classes)

🟠 The nouns give you the objects, each with one clear responsibility:

• ParkingLot — the top-level entity (often a Singleton); holds levels, coordinates parking.
• Level (floor) — holds a collection of spots.
• ParkingSpot — a single spot with a type and free/occupied status.
• Vehicle — abstract, with subtypes Motorcycle / Car / Truck (each needs a spot size).
• Ticket — issued on entry; records vehicle, spot, entry time.
• Payment / PricingStrategy — computes the fee.

Step 3 — The class diagram

ParkingLot composes Levels (a level has no meaning without the lot); a Level composes ParkingSpots; Vehicle is an inheritance hierarchy; a Ticket associates a Vehicle with a Spot. That's the whole structure.

Step 4 — The design decisions that score points

🔴 The interviewer is really watching for good OOD choices and pattern use:

• Spot assignment = Strategy: "find nearest spot" vs "find by level" vs "first available" are interchangeable algorithms — put spot-finding behind a ParkingStrategy interface so you can swap it without touching the lot.
• Pricing = Strategy too: hourly, flat, weekend rates → a PricingStrategy. New pricing = new class (Open/Closed).
• Object creation = Factory: a VehicleFactory creates the right vehicle subtype from input.
• ParkingLot = Singleton: there's one lot instance the system shares.
• Enums for types & status: VehicleType, SpotType, SpotStatus{FREE,OCCUPIED} — clearer than magic strings.

class ParkingLot {                       // Singleton
    private List<Level> levels;
    private ParkingStrategy strategy;     // Strategy: how to pick a spot
    public Ticket park(Vehicle v) {
        ParkingSpot spot = strategy.findSpot(levels, v);
        if (spot == null) throw new LotFullException();
        spot.assign(v);
        return new Ticket(v, spot, now());
    }
    public double unpark(Ticket t, PricingStrategy pricing) {
        t.getSpot().release();
        return pricing.calculate(t.getEntryTime(), now());
    }
}

Step 5 — Handling the tricky bits

🟠 Mention these unprompted: concurrency — two cars racing for the last spot need the spot assignment to be thread-safe (synchronize or use atomic status); spot fit — a truck needs a large spot, a bike fits anywhere (map vehicle type → allowed spot types); and full lot — return/throw gracefully rather than NPE. These edge cases separate a solid answer from a great one.

The interview-ready walkthrough

"I'd extract classes from the nouns: ParkingLot (Singleton) composing Levels, each composing ParkingSpots; a Vehicle hierarchy; and a Ticket. I'd use Strategy for spot-assignment and pricing (so they're swappable and Open/Closed), a Factory for vehicles, and enums for types/status. park() asks the strategy for a suitable free spot, assigns it, and issues a ticket; unpark() releases the spot and prices by duration. I'd make spot assignment thread-safe for the last-spot race and handle vehicle-to-spot fit and the full-lot case." That's a clean, pattern-backed, extensible design — exactly what the round rewards."

What to read next

• Design an Elevator System — the next classic LLD problem
• Strategy Pattern — used here for spot & pricing logic
• LLD Interview: How to Approach — the general method
• ← The complete System Design guide (hub)

← Design patterns hub · Design an elevator system →