TLDR

TLDR: A Parking Lot is the "Hello World" of Low-Level Design. It teaches Encapsulation (ParkingFloor hides its Min-Heap), Abstraction (PricingStrategy interface), Inheritance (BikeSpot/CompactSpot/LargeSpot extend ParkingSpot), and Polymorphism (type dispatch without casting). Factory Pattern for vehicles, Strategy Pattern for pricing, O(log n) Min-Heap for allocation.

---

📖 The Mall Garage Problem

You pull up to a mall garage. Three things happen:

1. Entry gate: You press a button → get a ticket → gate opens.
2. Parking: Find a spot (the system might display "Floor 2, Spot 14").
3. Exit: Scan your ticket → system calculates fee based on time parked → gate opens.

The software behind this manages hundreds of concurrent vehicles across multiple floors, spot types, and pricing tiers.

---

🔍 Parking Lot Design Basics

Before writing any code, it helps to map out the real-world entities the system must represent.

Spot Types — Not every bay fits every vehicle. A typical garage divides its spaces into three tiers:

Vehicle Types — Each vehicle carries a licensePlate and a VehicleType enum (BIKE, CAR, TRUCK). The type determines which spot tier it can occupy — a TRUCK cannot squeeze into a CompactSpot.

Ticket — When a vehicle enters, the system issues a Ticket that records three things: the vehicle (plate + type), the assigned spot (floor number + spot ID), and the entry timestamp. The ticket is the single source of truth for pricing at exit.

Pricing — Fees are computed at exit from the ticket's entry timestamp and the vehicle type. A TRUCK costs more per hour than a CAR, which costs more than a BIKE. The exact rates are pluggable — more on that in the Strategy Pattern section.

The Core Loop in plain English:

1. Vehicle arrives → system finds the nearest free compatible spot → issues a ticket.
2. Vehicle leaves → system reads the ticket → calculates fee from duration × rate → releases the spot → driver pays.

Understanding these five entities (Spot, Vehicle, Ticket, Floor, Lot) makes the class diagram and pattern choices in the next sections click immediately.

---

🔢 The Domain Model

classDiagram
    class ParkingLot {
        -static ParkingLot instance
        +List~ParkingFloor~ floors
        -PricingStrategy pricingStrategy
        +Ticket park(Vehicle v)
        +double exit(Ticket t)
    }
    class ParkingFloor {
        +int floorNumber
        -Map~VehicleType,PriorityQueue~ heaps
        +ParkingSpot findNearest(VehicleType t)
        +void releaseSpot(ParkingSpot s)
    }
    class ParkingSpot {
        <>
        +int id
        +boolean isFree
        +VehicleType type
        +void assign(Vehicle v)
        +void free()
    }
    class BikeSpot {
        +VehicleType type = BIKE
    }
    class CompactSpot {
        +VehicleType type = CAR
    }
    class LargeSpot {
        +VehicleType type = TRUCK
    }
    class Vehicle {
        <>
        +String licensePlate
        +VehicleType type
    }
    class Bike
    class Car
    class Truck
    class Ticket {
        +Vehicle vehicle
        +ParkingSpot spot
        +Instant entryTime
    }
    class PricingStrategy {
        <>
        +calculateFee(VehicleType type, long minutes) double
    }
    class HourlyPricing {
        +calculateFee(VehicleType type, long minutes) double
    }

    ParkingLot "1" *-- "many" ParkingFloor : owns
    ParkingFloor "1" *-- "many" ParkingSpot : contains
    BikeSpot --|> ParkingSpot : extends
    CompactSpot --|> ParkingSpot : extends
    LargeSpot --|> ParkingSpot : extends
    Bike --|> Vehicle : extends
    Car --|> Vehicle : extends
    Truck --|> Vehicle : extends
    Ticket --> Vehicle : records
    Ticket --> ParkingSpot : records
    ParkingLot o-- PricingStrategy : uses
    HourlyPricing ..|> PricingStrategy : implements

Hierarchy:

• ParkingSpot → subclasses: BikeSpot, CompactSpot, LargeSpot
• Vehicle → subclasses: Bike, Car, Truck
• ParkingLot → Singleton (one physical lot, one controller)

---

🧱 OOP Pillars in the Parking Lot Domain

The four OOP pillars are not abstract ideals here — each one maps to a concrete class or interface in this design.

Encapsulation — ParkingFloor hides its Min-Heap

ParkingFloor owns a Map<VehicleType, PriorityQueue<ParkingSpot>> internally. No external class ever touches that map directly. The public surface is exactly two methods: findNearest(VehicleType) (wraps poll()) and releaseSpot(ParkingSpot) (wraps offer()). Callers never manipulate the heap — so the internal structure can be swapped from PriorityQueue to TreeSet without changing a single line outside ParkingFloor.

Abstraction — PricingStrategy and ParkingSpot hide the HOW

PricingStrategy exposes one method: calculateFee(VehicleType, long minutes). Callers know what it computes (a fee), never how hourly or dynamic pricing does it. Similarly, ParkingSpot as an abstract class exposes assign(Vehicle) and free() — callers never need to know whether the underlying spot is a narrow bike bay or a wide truck stall.

Inheritance — The Spot and Vehicle Hierarchies

BikeSpot extends ParkingSpot inherits the assign(Vehicle) / free() lifecycle from the abstract base, overriding only getCompatibleType() to return VehicleType.BIKE. Adding EVSpot later is one new subclass — the entire lifecycle is already implemented in the base class.

Polymorphism — Type Dispatch Without Casting

ParkingFloor stores PriorityQueue<ParkingSpot> entries that hold BikeSpot, CompactSpot, or LargeSpot instances — all referenced as ParkingSpot. findNearest(VehicleType.CAR) dispatches to the correct heap and returns a ParkingSpot reference; the caller never casts. Similarly, VehicleFactory.create() always returns a Vehicle reference regardless of whether it built a Bike, Car, or Truck.

---

⚙️ Finding the Nearest Spot: Min-Heap

A naive O(N) linear scan through all spots is too slow for a large garage.

Optimized: Use a Min-Heap (priority queue ordered by spot ID, lowest = nearest entrance) per vehicle type per floor.

Floor 1 Compact Heap: [101, 103, 107, ...]   ← pop 101 in O(log N)
Floor 1 Large Heap:   [150, 155, ...]

Operations:

• findNearest(CAR) → heaps.get(CAR).poll() → O(log N)
• releaseSpot(spot) → heaps.get(spot.type).offer(spot) → O(log N)

For N = 1000 spots per floor: log₂(1000) ≈ 10 operations vs. 1000 for linear scan.

---

🧠 Deep Dive: Factory and Strategy Patterns

public class VehicleFactory {
    public static Vehicle create(VehicleType type, String plate) {
        return switch (type) {
            case BIKE   -> new Bike(plate);
            case CAR    -> new Car(plate);
            case TRUCK  -> new Truck(plate);
        };
    }
}

Callers use VehicleFactory.create(VehicleType.CAR, "ABC-123") — never new Car(...) directly. This decouples object creation from business logic and makes it easy to add ElectricVehicle later.

---

⚙️ Strategy Pattern for Pricing

Pricing rules vary (hourly, daily, weekend, EV charging surcharge):

public interface PricingStrategy {
    double calculateFee(VehicleType type, long parkingMinutes);
}

public class HourlyPricing implements PricingStrategy {
    public double calculateFee(VehicleType type, long minutes) {
        double ratePerHour = type == VehicleType.TRUCK ? 3.50 :
                             type == VehicleType.CAR   ? 2.00 : 1.00;
        return ratePerHour * Math.ceil(minutes / 60.0);
    }
}

The ParkingLot holds a reference to any PricingStrategy. Swapping from HourlyPricing to DynamicPricing requires zero changes to the rest of the code.

---

📐 Interface Contracts

Every behavioral variation point in the design is expressed as a Java interface. These are the two core contracts that decouple callers from implementations:

/**
 * Abstracts: the fee calculation algorithm (hourly, daily, dynamic, EV surcharge).
 * Implemented by: HourlyPricing, DailyPricing, DynamicPricing, ChargingPricing.
 * Consumed by: ParkingLot.exit(Ticket) — calls calculateFee() without knowing the concrete rule.
 */
interface PricingStrategy {
    double calculateFee(VehicleType type, long parkingMinutes);
}

/**
 * Abstracts: nearest-spot lookup and release across all floors.
 * Implemented by: NearestFirstAllocator (Min-Heap), RoundRobinAllocator.
 * Consumed by: ParkingLot.park(Vehicle) — delegates floor traversal to the allocator.
 */
interface SpotAllocator {
    Optional<ParkingSpot> findNearest(VehicleType type, List<ParkingFloor> floors);
    void release(ParkingSpot spot, List<ParkingFloor> floors);
}

Both interfaces are intentionally minimal — each covers one behavioral axis. PricingStrategy does exactly one thing: compute a fee. SpotAllocator does exactly one thing: find and release spots. Neither interface carries unrelated methods that would force implementors to stub out no-ops.

---

✅ SOLID Principles in the Parking Lot Design

OCP in action — adding EV support without touching any existing class:

// New subclass only — ParkingSpot, ParkingFloor, ParkingLot all untouched
public class EVSpot extends ParkingSpot {
    public EVSpot(int id) { super(id, VehicleType.ELECTRIC_CAR); }
}

// New strategy only — implements the existing interface
public class ChargingPricing implements PricingStrategy {
    private static final double CHARGE_RATE_PER_MIN = 0.25;
    private final PricingStrategy base = new HourlyPricing();

    @Override
    public double calculateFee(VehicleType type, long minutes) {
        return base.calculateFee(type, minutes) + (CHARGE_RATE_PER_MIN * minutes);
    }
}

ParkingLot, ParkingFloor, Ticket, and every other existing class remain untouched. Two new classes added, zero classes modified. This is the Open/Closed Principle as a concrete code change, not a theoretical promise.

---

⚖️ Trade-offs & Failure Modes in Parking Lot Design

---

📊 How Parking Works: End-to-End Flow

Every parking interaction follows a predictable lifecycle — from the moment a car joins the entry queue to the moment the exit barrier lifts. The diagram below traces that full path through the system.

flowchart TD
    A[Vehicle Arrives at Entry Gate] --> B{Compatible Spot Available?}
    B -- No --> C[Display 'Lot Full' & Reject Vehicle]
    B -- Yes --> D[Allocate Nearest Spot\nMin-Heap pop → O log N]
    D --> E[Issue Ticket\nvehicle + spot + entryTime]
    E --> F[Vehicle Parks in Assigned Spot]
    F --> G[Vehicle Returns to Exit Gate]
    G --> H[Driver Scans Ticket]
    H --> I[Calculate Fee\nduration × rate via PricingStrategy]
    I --> J[Driver Pays Fee]
    J --> K[Release Spot\nMin-Heap offer → O log N]
    K --> L[Exit Gate Opens]

What makes this non-trivial at scale:

• Step D must complete in O(log N) — slow allocation creates entry-gate queues that back up into the street.
• Step I must be strategy-swappable — pricing rules change for holidays, EV charging surcharges, and peak-hour tariffs without any structural code change.
• Step K must be thread-safe — dozens of exits can fire simultaneously; without locking, two gate threads can both read the same spot as "available" and double-allocate it.

The two Min-Heap operations (D and K) are symmetric: poll() at entry, offer() at exit. This keeps the heap always consistent with the real state of the floor.

---

🌍 Real-World Applications of Parking Lot Design

The Factory + Strategy + Min-Heap combination is not academic — the same structural decisions appear across a broad range of deployed parking infrastructure.

Airport Garages — Large multi-level garages display real-time availability counts above each lane ("Floor 3 — 47 spots free"). The Min-Heap allocation logic maps directly to the software that decrements and increments those counters per floor, per spot tier.

Hospital Parking Systems — Hospitals add priority spot categories: accessible bays, ambulance zones, reserved staff spaces. The ParkingSpot hierarchy (BikeSpot, CompactSpot, LargeSpot) extends naturally to AccessibleSpot and ReservedSpot without touching allocation or pricing logic.

Smart City Parking Apps — Apps like ParkWhiz and SpotHero expose real-time APIs backed by lot management systems. The Strategy Pattern for pricing maps directly to dynamic rate engines that adjust fees by time of day, demand level, and event proximity. Injecting a DemandBasedPricing strategy requires zero changes to the core lot controller.

EV Charging Stations — Charging-enabled spots add a per-minute electricity surcharge on top of the parking rate. A ChargingPricing strategy encapsulates that logic cleanly — the rest of the system never needs to know a charging cable is involved.

The same three patterns scale from a 50-space surface lot to a 5,000-space multi-level garage with minimal structural change.

---

🧪 Practical Exercises: Extending the Design

Try these exercises to move from reading to building:

Exercise 1 — Add an Electric Vehicle Spot Type The current design has BikeSpot, CompactSpot, and LargeSpot. Add an EVSpot that can only be assigned to ElectricCar vehicles. Steps: (a) add ELECTRIC_CAR to VehicleType; (b) add ElectricCar to VehicleFactory; (c) implement ChargingPricing that adds $0.25/min on top of the base HourlyPricing rate; (d) inject it into ParkingLot at startup.

Exercise 2 — Multi-Level Nearest-Spot Search The current ParkingLot.park() only searches Floor 1. Modify it to iterate through all floors and return the globally nearest spot (lowest floor number wins; tie-break by lowest spot ID). Benchmark: how does the search time grow as you add floors?

Exercise 3 — Thread-Safe Concurrent Entry Gates Simulate two vehicles arriving in the same millisecond. What happens if two gate threads both call findNearest(CAR) simultaneously on the same floor? Add a ReentrantLock (or synchronized block) to ParkingFloor.findNearest() and releaseSpot(). Write a JUnit test using two threads to verify no spot is ever double-allocated.

Each exercise directly extends one design decision from this article — Factory extension, allocation scope, and thread safety respectively.

---

📚 Key Lessons from Designing a Parking Lot System

• Singleton prevents duplicate state — a parking lot is one physical system; one controller instance with one source of truth stops inconsistent spot counts across gate threads.
• Min-Heap is the right data structure for "find nearest" — O(log N) poll/offer beats O(N) linear scan at any non-trivial garage size; 1,000 spots means ~10 operations vs. 1,000.
• Factory decouples creation from business logic — adding a new vehicle type (ElectricCar, Motorbike) is a one-class change that never touches gate, floor, or payment code.
• Strategy makes pricing pluggable — new fee rules are new classes, not edits to existing ones. This is the Open/Closed Principle in concrete action.
• Thread safety is not optional — concurrent entry gates without locking produce double-allocation bugs that are rare, hard to reproduce in tests, and expensive to diagnose in production.

---

🧭 Decision Guide: When to Apply These Parking Lot Patterns

Start simple: a flat HashMap<SpotId, Spot> works for a garage under 50 spots. Add the Min-Heap only when profiling shows allocation latency. Apply Factory and Strategy from the start — they add one interface each and pay back immediately when requirements change.

---

📌 TLDR: Summary & Key Takeaways

• Singleton ParkingLot prevents duplicate instance state.
• Min-Heap per vehicle type per floor → O(log N) nearest-spot allocation vs. O(N) naive scan.
• Factory Pattern decouples vehicle creation from business logic.
• Strategy Pattern keeps pricing rules pluggable and testable in isolation.
• See the companion post Implement LLD for Parking Lot for the full thread-safe Java implementation.

---

📝 Practice Quiz

1. Why is a Min-Heap better than a List for tracking available spots?

   • A) Min-Heap supports more vehicle types.
   • B) Min-Heap gives O(log N) for nearest-spot pop and spot release vs O(N) linear scan.
   • C) Min-Heap prevents overlapping spots.
     Correct Answer: B — A Min-Heap (priority queue) gives O(log N) for both poll() (allocate nearest) and offer() (release spot), compared to O(N) for scanning a list every time.

2. What does the Factory Pattern give you in vehicle creation?

   • A) Thread safety for concurrent gate access.
   • B) A single creation point that decouples new Car() from business logic, making it easy to extend with new types.
   • C) A way to pool and reuse Vehicle objects.
     Correct Answer: B — Factory Pattern centralises all vehicle construction in VehicleFactory.create(), so callers never use new Car() directly. Adding ElectricCar later means one new class and one new switch case — nothing else changes.

3. You want to add "peak-hour surcharge" pricing. With the Strategy Pattern, how many existing classes do you need to change?

   • A) All classes that calculate fees.
   • B) Zero — create a new PeakHourPricing implements PricingStrategy and inject it into ParkingLot.
   • C) ParkingLot, Ticket, and ParkingFloor all need updates.
     Correct Answer: B — Strategy Pattern means zero modifications to existing classes. You write PeakHourPricing implements PricingStrategy, inject it into ParkingLot, and the rest of the system is untouched. This is the Open/Closed Principle in practice.

---

🛠️ Spring Boot and MapStruct: Wiring the Parking Lot Domain to a REST Layer

Spring Boot turns the ParkingLot domain model into a running web service with zero XML configuration — @SpringBootApplication auto-configures the IoC container, embedded Tomcat, and Jackson JSON serialization. MapStruct generates type-safe, reflection-free mapping code between domain objects (ParkingSpot, Ticket) and REST response DTOs, eliminating the manual target.setField(source.getField()) boilerplate that violates DRY across multiple controllers.

How they solve the problem in this post: The ParkingLotService becomes a Spring @Service singleton that the @RestController receives via constructor injection. MapStruct generates ParkingSpotMapper.toDto(ParkingSpot) at compile time, so the controller never reaches directly into the domain model — maintaining a clean separation between the REST representation and the internal domain.

// ─── REST DTO — what the API returns (no domain logic) ───────────────────────
public record ParkingSpotDto(int id, String type, boolean available, int floor) {}
public record TicketDto(String ticketId, String plate, String vehicleType,
                        int floor, int spotId, String entryTime) {}

// ─── MapStruct mapper — compile-time generated, zero reflection ───────────────
// Dependency: org.mapstruct:mapstruct:1.5.5 + mapstruct-processor (annotationProcessor)
import org.mapstruct.Mapper;
import org.mapstruct.Mapping;

@Mapper(componentModel = "spring")  // generates a Spring @Component bean
public interface ParkingSpotMapper {
    @Mapping(source = "free", target = "available")
    ParkingSpotDto toDto(ParkingSpot spot);
}

// ─── Spring service: wraps ParkingLot Singleton ───────────────────────────────
import org.springframework.stereotype.Service;

@Service
public class ParkingLotService {

    private final ParkingLot lot = ParkingLot.getInstance();

    public TicketDto park(String plate, VehicleType type) {
        Vehicle v = VehicleFactory.create(plate, type);
        Ticket t  = lot.park(v).orElseThrow(() ->
                new org.springframework.web.server.ResponseStatusException(
                    org.springframework.http.HttpStatus.CONFLICT,
                    "No spot available for " + type));
        return new TicketDto(t.getId(), plate, type.name(),
                             t.getFloor(), t.getSpotId(),
                             t.getEntryTime().toString());
    }

    public double exit(String ticketId) {
        return lot.exit(ticketId);
    }
}

// ─── REST controller ─────────────────────────────────────────────────────────
import org.springframework.http.*;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/v1/parking")
public class ParkingLotController {

    private final ParkingLotService service;
    private final ParkingSpotMapper mapper;

    public ParkingLotController(ParkingLotService service, ParkingSpotMapper mapper) {
        this.service = service;
        this.mapper  = mapper;
    }

    /** POST /api/v1/parking/enter?plate=MH01AB1234&type=CAR */
    @PostMapping("/enter")
    public ResponseEntity<TicketDto> enter(
            @RequestParam String plate,
            @RequestParam VehicleType type) {
        return ResponseEntity.status(HttpStatus.CREATED).body(service.park(plate, type));
    }

    /** DELETE /api/v1/parking/exit/{ticketId} → returns fee */
    @DeleteMapping("/exit/{ticketId}")
    public ResponseEntity<Map<String, Object>> exit(@PathVariable String ticketId) {
        double fee = service.exit(ticketId);
        return ResponseEntity.ok(Map.of("ticketId", ticketId, "fee", fee));
    }
}

@Mapper(componentModel = "spring") tells MapStruct to generate a @Component-annotated implementation class, so Spring auto-discovers and injects it like any other bean. The generated code is plain Java with direct field access — 5–10× faster than ModelMapper and catches field-name mismatches at compile time, not at runtime.

For a full deep-dive on Spring Boot REST layer patterns and MapStruct advanced mapping, a dedicated follow-up post is planned.

---

🔗 Related Posts

• Implement LLD for Parking Lot — Full Thread-Safe Java Code
• LLD for URL Shortener
• LLD for Elevator System
• LLD for Movie Booking System
• LLD for LRU Cache — Designing a High-Performance Cache
• Single Responsibility Principle
• Strategy Design Pattern — Simplifying Software Design

---