Design a Multi-Floor Parking Lot
In a 45-minute LLD interview, the key focus is multi-dimensional strategy decoupling (allocating spots across floors vs calculating dynamic exit fees), entity hierarchy with compatibility constraints (vehicles fitting into equal or larger spot categories), and lifecycle consistency (issuing immutable tickets on entry, reclaiming spots and computing tariffs on exit). Scope to multi-floor management, three spot types (MOTORCYCLE, COMPACT, LARGE), swappable allocation (SpotAllocationStrategy), swappable pricing (PricingStrategy), and ticket tracking. Mention concurrent multi-gate sync and EV charging spot decorators as extensions.
Problem statement & clarifying requirements
Design a Multi-Floor Parking Lot management system. The facility must accommodate diverse vehicle types (Motorcycles, Cars, Trucks) in designated spot sizes across multiple floors. The system must support pluggable spot allocation strategies (such as lowest-floor-first or nearest-to-entrance), swappable pricing models (hourly duration vs flat rates), ticket generation upon entry, and reliable spot reclamation upon exit.
Three spot sizes: MOTORCYCLE, COMPACT, and LARGE. Motorcycles can park in any available spot (preferring Motorcycle). Cars fit in Compact or Large spots. Trucks can fit only in Large spots.
Use the Strategy pattern (SpotAllocationStrategy). The default strategy is LowestFloorFirstStrategy, which fills lower floors completely and exact-fit spots first before exploring higher floors or larger spots.
Use the Strategy pattern (PricingStrategy). The default model is HourlyPricingStrategy charging differentiated rates (e.g. ₹20/hr for bikes, ₹50/hr for cars, ₹100/hr for trucks) with minimum 1-hour billing.
A ParkingLotManager singleton facade coordinates the multi-floor facility, using a TicketFactory to stamp tickets on entry and managing active tickets in an in-memory hash map until exit.
First, sketch the design yourself
Spend 5 minutes listing the classes, who owns whom, and which interface hides the part that changes.
- 1.
Never hardcode allocation logic or pricing formulas inside
ParkingLotManager. Decouple both axes using the Strategy pattern (SpotAllocationStrategyandPricingStrategy). - 2.
Encapsulate spot dimensions and occupancy state cleanly within
ParkingSpot, ensuring thread safety and clear ownership across multi-floor vectors. - 3.
Use a dedicated
TicketFactory(Factory Method) to stamp tickets with auto-incrementing identifiers, vehicle metadata, spot coordinates, and entry timestamps.
How to think through this problem (5-step walkthrough)
In a 45-minute LLD interview, the key focus is multi-dimensional strategy decoupling (allocating spots across floors vs calculating dynamic exit fees), entity hierarchy with compatibility constraints (vehicles fitting into equal or larger spot categories), and lifecycle consistency (issuing immutable tickets on entry, reclaiming spots and computing tariffs on exit). Scope to multi-floor management, three spot types (MOTORCYCLE, COMPACT, LARGE), swappable allocation (SpotAllocationStrategy), swappable pricing (PricingStrategy), and ticket tracking. Mention concurrent multi-gate sync and EV charging spot decorators as extensions.
Not every noun in the prompt deserves its own class. Separate dumb data structs from stateful managers, and turn trivial nouns into fields or enums.
VehicleValue struct bundling licensePlate string and VehicleType enum (MOTORCYCLE, CAR, TRUCK).
ParkingTicketImmutable value struct linking ticketId, vehicle plate, floor number, spot number, and entry hour.
ParkingSpotRepresents an individual physical bay with floor, spot number, SpotType, and occupancy flag (park(), unpark(), isAvailable()).
SpotAllocationStrategyPluggable strategy contract (findSpot(floors, vehicleType)) decoupling spot search algorithms (lowest floor first, nearest to elevator, round-robin).
PricingStrategyPluggable tariff contract (calculateFee(ticket, exitHour)) allowing hourly, flat, peak-hour, or weekend pricing without modifying the lot manager.
ParkingLotManagerSingleton facade coordinating the floors, holding active tickets in an in-memory hash map, and orchestrating entry/exit flows.
LicensePlate / GateArmTrap noun — beginners often create separate LicensePlate or GateArm classes. A license plate is easily modeled as a std::string field on Vehicle, and a physical gate arm is a hardware peripheral triggered by parkVehicle returning a valid ticket, not an in-memory business entity.
A naive implementation embeds nested loops directly inside ParkingLot::park(vehicle) to find the first open spot and hardcodes fee = hours * 50 inside ParkingLot::unpark(). When management asks to fill Floor 1 before Floor 2, or introduce weekend surge pricing, developers must edit the monolithic ParkingLot class. Furthermore, without spot sizing rules, a naive system parks a motorcycle in a truck bay while a truck is turned away.
Hardcoding floor and bay traversal directly inside ParkingLotManager prevents adding VIP priority, nearest-to-exit heuristics, or load-balancing across floors.
Embedding fee formulas in the unparking workflow breaks OCP whenever rates change (hourly vs flat rates vs vehicle-tiered multipliers).
Instantiating multiple independent lot managers risks desynchronizing floor counts and assigning the same spot to two vehicles.
- ✓
Vehicle-to-spot compatibility invariant: Smaller vehicles may occupy equal or larger spots (
canFit(vehicleType, spotType)), but oversized vehicles (e.g. trucks) must never be assigned undersized bays (e.g. motorcycle or compact spots). - ✓
Ticket uniqueness and spot exclusivity invariant: A ticket is generated with a unique identifier upon entry, and the assigned
ParkingSpotremainsoccupied_ == trueuntil that specific ticket is redeemed at exit. - ✓
Safe ticket redemption:
unparkVehiclevalidates the existence of the ticket ID in active tickets, frees the spot, computes fees using integer arithmetic, and removes the ticket from active tracking in one cohesive operation.
Entities & design patterns used
Unlock Full UML Diagram & C++23 Solution
The complete UML diagram, production-ready C++23 code, follow-up extensions, and design pitfall analysis are part of Brute2Best Pro. All 7 foundation chapters are 100% free.
First anchor question per pattern, Part 1 LLD & Module 1 C++ basics are 100% Free forever.