Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
LLD Case Study: Elevator System (Scheduling, State Machines, Concurrency)
Production-grade object-oriented elevator system design covering SCAN scheduling, state machine modeling, multi-elevator coordination, and failure modes. Covers what most prep resources get wrong: the difference between SCAN and LOOK, and why nearest-car is correct for modern buildings.
Why Elevator Is a Different Class of LLD Problem
Parking lot tests entity modeling. Elevator tests behavioral modeling — the system's complexity is not in what exists (the entities are simple: Building, Elevator, Request) but in how things behave over time. The elevator is always in a state, always transitioning between states, always executing an algorithm that determines its next action. This makes elevator a vehicle for testing three things simultaneously: state machines, scheduling algorithms, and multi-actor concurrency.
The problem has three distinct layers that most candidates collapse into one:
- Hardware layer — Door, Motor, DisplayPanel, Button, WeightSensor. Each has its own state.
- Domain layer — Elevator, Floor, Request. This is where scheduling lives.
- Coordination layer — ElevatorController, ElevatorBank. Distributes requests across multiple elevators.
Collapse these layers and you get an Elevator class with 400 lines, a process() method with nested conditionals, and a design that breaks the moment you add "maintenance mode" or "hospital emergency override." Separate them and each layer is independently testable and extensible.
The non-obvious insight: In a real elevator system, the elevator does not decide which floor to service next — the controller does. The elevator just executes: move to a floor, open doors, close doors. The scheduling intelligence lives entirely in ElevatorController. This separation is what most candidates miss, and it is the first thing senior interviewers probe.
Clarifying Questions — Scope Before Design
Physical constraints
How many elevators? How many floors? What is the max load per elevator (persons or kg)? Is there a basement or only above-ground floors? These determine data structure choices — a small building (10 floors, 2 elevators) needs different scheduling tuning than a skyscraper (100 floors, 20 elevators).
Building type
Office (heavy 8–10am, 5–7pm bidirectional peaks), residential (lighter, more random), hospital (must prioritize Code Blue / emergency calls, dedicated service elevator for gurneys), data center (freight-only). Building type determines whether you need priority queuing and special operating modes.
Request types
External request: passenger presses Up/Down on a floor panel. Internal request: passenger presses a floor button inside the elevator. Are these treated the same or differently? (They are different — external requests have a direction, internal requests have a destination.)
Special modes
Emergency mode (all elevators return to ground floor and open doors — fire evacuation)? Maintenance mode (elevator goes out of service, doors locked)? VIP mode (specific elevator dedicated to an executive floor)? These require special state transitions.
Accessibility
Extended door-hold time for wheelchair users? Floor announcements (audio)? Braille buttons? These are UI concerns, not scheduling concerns, but they affect the Door state machine (OPEN state has a timeout that can be extended).
Scheduling algorithm
Explicitly ask: 'Should I optimize for average wait time, peak throughput, or fairness?' The answer changes which algorithm to implement — SCAN favors throughput, nearest-car favors average wait time, LOOK balances both.