How to Design a Parking Lot System | LLD Interview Guide

The Parking Lot system is one of the most frequently asked Low Level Design problems in software engineering interviews. Companies like Amazon, Flipkart, Microsoft, and Uber use this problem to evaluate your understanding of Object-Oriented Design, SOLID principles, and design patterns. In this guide, we'll walk through the complete solution from requirements to code structure.

Why Interviewers Ask This Problem

The Parking Lot problem is deceptively simple on the surface but reveals a lot about how you think. Interviewers want to see:

• Can you identify the right entities without over-engineering?
• Do you apply the Single Responsibility Principle?
• Can you use the Strategy pattern for extensible pricing?
• Do you think about edge cases like concurrent access?

Requirements Breakdown

Before writing a single class, clarify the requirements. Here's what a complete Parking Lot system needs:

• Multiple floors, each with configurable slot counts
• Three vehicle types: Bike, Car, Truck (each needs different slot size)
• Allocate the nearest available slot to an incoming vehicle
• Generate a ticket on entry, calculate fee on exit
• Different pricing per vehicle type
• Free up the slot when a vehicle exits

A common mistake is jumping to code before asking these questions. Always spend 3–5 minutes on requirements gathering in an interview.

Identifying Core Entities

The key to LLD is identifying the right nouns from the requirements. For the Parking Lot:

• ParkingLot — the top-level entry point, manages floors
• Floor — contains slots, knows its floor number
• Slot — has a size (Small/Medium/Large) and holds one vehicle
• Vehicle — abstract class with Bike, Car, Truck as subtypes
• Ticket — records entry time, vehicle, and assigned slot
• PricingStrategy — calculates fee based on vehicle type and duration

Class Structure

// Vehicle hierarchy
abstract class Vehicle {
  licensePlate: string;
  abstract getSize(): VehicleSize;
}
class Bike extends Vehicle { getSize() { return VehicleSize.SMALL; } }
class Car  extends Vehicle { getSize() { return VehicleSize.MEDIUM; } }
class Truck extends Vehicle { getSize() { return VehicleSize.LARGE; } }

// Slot
class Slot {
  id: string;
  floor: number;
  size: VehicleSize;
  isOccupied: boolean;
  vehicle: Vehicle | null;
}

// Ticket issued on entry
class Ticket {
  ticketId: string;
  vehicle: Vehicle;
  slot: Slot;
  entryTime: Date;
}

// Strategy interface for pricing
interface PricingStrategy {
  calculateFee(vehicle: Vehicle, durationMinutes: number): number;
}

// ParkingLot — the facade
class ParkingLot {
  floors: Floor[];
  pricing: PricingStrategy;

  parkVehicle(vehicle: Vehicle): Ticket | null { ... }
  exitVehicle(ticket: Ticket): number { ... }  // returns fee
}

Key Design Decision: Strategy Pattern for Pricing

Pricing varies by vehicle type and could change (surge pricing, monthly passes). Using the Strategy pattern keeps the core ParkingLot class closed for modification but open for extension — this is the Open/Closed Principle in action.

class HourlyPricing implements PricingStrategy {
  private rates = {
    [VehicleSize.SMALL]:  20,  // ₹20/hr for bikes
    [VehicleSize.MEDIUM]: 40,  // ₹40/hr for cars
    [VehicleSize.LARGE]:  80,  // ₹80/hr for trucks
  };

  calculateFee(vehicle: Vehicle, durationMinutes: number): number {
    const hours = Math.ceil(durationMinutes / 60);
    return this.rates[vehicle.getSize()] * hours;
  }
}

Finding the Nearest Slot

Iterating floor by floor, slot by slot gives you the nearest slot without complex data structures. For a real system you'd use a priority queue, but in an interview, a clean linear scan is acceptable and easier to reason about.

parkVehicle(vehicle: Vehicle): Ticket | null {
  for (const floor of this.floors) {
    const slot = floor.findAvailableSlot(vehicle.getSize());
    if (slot) {
      slot.assignVehicle(vehicle);
      return new Ticket(vehicle, slot, new Date());
    }
  }
  return null; // Parking full
}

Common Mistakes Interviewers Look For

• Putting pricing logic in Vehicle or Slot — violates SRP. Pricing belongs in its own strategy.
• Using if-else for vehicle type matching — use polymorphism instead.
• Not separating Ticket from Vehicle — a vehicle can have multiple tickets across visits.
• Forgetting thread safety — in a real system, slot allocation must be synchronized.

Follow-up Questions Interviewers Ask

• "How would you support monthly passes?" → Add a PricingStrategy subclass
• "How would you handle concurrent entries?" → Synchronize slot allocation, use optimistic locking
• "How would you add EV charging slots?" → Add a ChargeableSlot subtype
• "How would you track revenue?" → Observer pattern — emit event on each payment

Which Companies Ask This

Amazon (SDE-2 onsite), Flipkart (LLD round), Microsoft (design round), Uber (backend engineer), Paytm, PhonePe, and most product-based companies in India use this as a screening LLD problem.