Design a Multi-Car Elevator System
In a 45-minute LLD interview, the key focus is modeling physical elevator kinematics, directional scheduling, and fleet dispatching. Scope the problem to: a commercial building with M elevator cars and N floors, handling corridor hall calls (HallRequest with floor and direction) and in-cabin button presses (CabinRequest with target floor), executing the directional LOOK sweep algorithm, and dispatching cars via cost heuristics. Discrete simulation ticks advance car positions.
Problem statement & clarifying requirements
Design a multi-car elevator system for a high-rise commercial building. The design must model the physical state machine of each elevator car (Idle, MovingUp, MovingDown), encapsulate hall and cabin button presses as executable commands, and efficiently assign cars to requests using the LOOK elevator scheduling algorithm and directional dispatch strategies.
Requests are split into Hall Requests (pressed from a floor corridor with a source floor and desired direction Up/Down) and Cabin Requests (pressed inside an elevator cabin specifying a destination floor).
Cars follow the LOOK algorithm (elevator sweep): a car continues servicing all requests in its current direction until no targets remain ahead, before reversing direction or returning to Idle.
A DispatchStrategy calculates a cost score for each car based on current floor distance, direction alignment (e.g. car is already moving towards the floor in the requested direction), and idle availability.
The system advances in discrete simulation ticks (step()), where each tick advances moving cars by one floor, opens doors upon reaching destination targets, and transitions state machines.
First, sketch the design yourself
Spend 5 minutes listing the classes, who owns whom, and which interface hides the part that changes.
- 1.
State Pattern (
a4) for car movement: State transitions betweenIdleState,MovingUpState, andMovingDownStatehave distinct movement rules and target scanning. Placing them in polymorphic state classes eliminates fragile nested switch statements insideElevatorCar. - 2.
Command Pattern (
b4) for decoupled requests: Both hall calls and cabin calls are encapsulated asElevatorCommandobjects (HallRequestandCabinRequest), decoupling request producers (hallway buttons, touchscreen panels) from target car queues. - 3.
Strategy Pattern (
a1) for pluggable dispatching: Dispatching logic evolves independently from physical car mechanics. IsolatingNearestDirectionalDispatcherbehindDispatchStrategyallows switching to Odd/Even or Zone dispatching without modifying elevator car internals.
How to think through this problem (5-step walkthrough)
In a 45-minute LLD interview, the key focus is modeling physical elevator kinematics, directional scheduling, and fleet dispatching. Scope the problem to: a commercial building with M elevator cars and N floors, handling corridor hall calls (HallRequest with floor and direction) and in-cabin button presses (CabinRequest with target floor), executing the directional LOOK sweep algorithm, and dispatching cars via cost heuristics. Discrete simulation ticks advance car positions.
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.
ElevatorStatePolymorphic State contract (IdleState, MovingUpState, MovingDownState) encapsulating directional motion, destination arrival, and LOOK sweep transitions without switch-case sprawl.
ElevatorCarPhysical elevator cabin holding car ID, current floor, door state, target floor sets (std::set<int>), and a std::unique_ptr<ElevatorState>.
ElevatorCommandCommand pattern contract (HallRequest, CabinRequest) encapsulating external corridor calls and internal cabin presses executed against target cars.
DispatchStrategyStrategy contract (NearestDirectionalDispatcher) evaluating fleet cars and selecting the optimal car for hall requests based on proximity and motion alignment.
ElevatorSystemCentral controller managing the fleet of cars, delegating hall calls to the dispatcher, and ticking the discrete simulation loop.
FloorNumber / DoorMotorTrap noun — creating dedicated classes for FloorNumber or DoorMotor overengineers the domain. A floor is a primitive int with range checks, and door state is an enum class DoorState { OPEN, CLOSED } toggled by openDoors() and closeDoors() member functions.
A beginner models an elevator with a giant while(true) loop full of nested switch statements (switch (status) { case MOVING: switch (dir) { ... } }) inside ElevatorCar. When adding door safety checks, reversing at terminal floors, or changing dispatching logic (e.g. from nearest car to odd/even zoning), code becomes an entangled mess of flag variables (isMoving, isGoingUp, doorsOpen) where state corruption easily leads to simulated crashes or infinite loops.
Nested conditionals checking directional flags make adding maintenance modes, emergency stops, or reverse sweeps fragile and bug-prone.
Hardcoding car assignment inside the central controller prevents adapting to morning up-peak rushes, evening down-peaks, or zoned building layouts.
Directly mutating car queues from corridor buttons couples physical button panels to car internals and makes request queuing or logging difficult.
- ✓
LOOK sweep invariant: An elevator moving in direction D must service all requested stops ahead along D before reversing direction or transitioning to
IdleState. - ✓
Door safety invariant: Elevator cars can only move between floors when doors are strictly
CLOSED. Upon reaching a target floor, movement halts, doors open to service passengers, the target floor is cleared from the target set, and doors close before the next tick. - ✓
Target set consistency: Target floors are stored in sorted collections (
std::set<int>) so directional searches (lower_bound/upper_bound) execute in O(log F) time without duplicate stops.
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.