Design a parking lot

Overview

Designing a parking lot is the most common LLD interview question. It tests whether you can turn vague requirements into entities, responsibilities, relationships, and extensible behavior, then write clean code for the core flows.

The key flows are parking a vehicle (find a compatible free spot and issue a ticket) and exiting (calculate the fee, take payment, and free the spot). Good designs keep spot allocation and pricing replaceable.

Requirements to clarify first

• Multiple floors, each with spots of types: motorcycle, compact, large, and electric.
• Vehicles: motorcycle, car, truck. A vehicle can only use compatible spot types.
• Entry issues a ticket; exit calculates a fee by duration and accepts payment.
• Show available spots per floor and type. Support multiple entry and exit gates concurrently.

Where it shows up in interviews

Where it is used in real software

Key terms

ParkingLot

Top-level facade with floors, gates, and the park/exit operations.

ParkingSpot

Has an ID, type, and current vehicle or null.

Ticket

Links a vehicle, a spot, and an entry time.

SpotAllocationStrategy

Chooses which free spot to assign (nearest, lowest floor, etc.).

PricingStrategy

Calculates the fee from ticket and exit time.

Interview approach

1. 1
   Clarify scope

   Confirm vehicle types, spot types, pricing model, payments, and concurrency. State non-goals such as reservations.

2. 2
   Identify entities

   ParkingLot, Floor, ParkingSpot, Vehicle, Ticket, Payment, Gate.

3. 3
   Assign responsibilities

   Spots know if they fit a vehicle. Floors track free spots. The lot coordinates allocation, tickets, and exit.

4. 4
   Extract what varies

   Allocation and pricing are strategies so new rules do not change the lot class.

5. 5
   Handle concurrency

   Two gates must never assign the same spot; lock or atomically claim spots.

6. 6
   Walk through flows

   Trace park and exit end to end, including the lot-full and invalid-ticket cases.

Vehicle to spot compatibility

Smallest fitting spot first to preserve large spots

Encoding compatibility in one table means adding a new vehicle type is a data change, not a rewrite of allocation logic.

Implementation

1enum VehicleType { Motorcycle = "MOTORCYCLE", Car = "CAR", Truck = "TRUCK" }2enum SpotType { Motorcycle = "MOTORCYCLE", Compact = "COMPACT", Large = "LARGE" }3 4const COMPATIBLE: Record<VehicleType, SpotType[]> = {5  [VehicleType.Motorcycle]: [SpotType.Motorcycle, SpotType.Compact, SpotType.Large],6  [VehicleType.Car]: [SpotType.Compact, SpotType.Large],7  [VehicleType.Truck]: [SpotType.Large],8};9 10class Vehicle {11  constructor(readonly plate: string, readonly type: VehicleType) {}12}13 14class ParkingSpot {15  private vehicle: Vehicle | null = null;16  constructor(readonly id: string, readonly type: SpotType, readonly floor: number) {}17 18  get isFree() { return this.vehicle === null; }19  canFit(vehicle: Vehicle) { return this.isFree && COMPATIBLE[vehicle.type].includes(this.type); }20  assign(vehicle: Vehicle) {21    if (!this.canFit(vehicle)) throw new Error(`Spot ${this.id} unavailable`);22    this.vehicle = vehicle;23  }24  release() { this.vehicle = null; }25}26 27class Ticket {28  constructor(29    readonly id: string,30    readonly vehicle: Vehicle,31    readonly spot: ParkingSpot,32    readonly entryTime: Date,33  ) {}34}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Putting all logic in ParkingLot.

  Fix: Give spots, tickets, and strategies their own responsibilities.

• Switch statements on vehicle type across the code.

  Fix: Use a compatibility table and polymorphic strategies.

• Ignoring concurrent gates.

  Fix: Describe locking or atomic claiming of a spot.

• Jumping into code before clarifying requirements.

  Fix: Spend the first minutes on scope, entities, and flows.

Interview questions

Practice problems