System Design › Low-Level Design

Design an Elevator System (Low-Level Design)

Design an elevator system in an LLD interview: modelling each elevator as a state machine with the SCAN movement algorithm, a controller that dispatches requests via a pluggable scheduling strategy, classes, and UML.

Shiv Pandey

Oct 25, 2026 | 4 views

Design an Elevator System (Low-Level Design)

🟠 Low-Level Design · Case Study · Senior

"Design an elevator system" is a favourite LLD problem because it's a rich state machine with a genuinely interesting decision: when someone presses a call button, which elevator should respond, and how does each elevator decide where to go next? That scheduling logic is the heart of the problem. Let's design it cleanly.

The approach in one line: model each Elevator as a state machine (moving up/down, idle, doors open) with a request queue, and a central controller that dispatches incoming requests to the best elevator using a pluggable scheduling strategy.

Step 1 — Requirements

Functional: a building with N floors and M elevators; two request types — external (up/down call from a floor) and internal (a floor button pressed inside a car); each elevator moves, stops, and opens/closes doors; the system dispatches external requests to an elevator.
Non-functional: minimise wait time, don't leave requests unserved, be extensible in the scheduling algorithm.

Step 2 — The classes

ElevatorSystem / Controller — receives external requests, dispatches to an elevator (holds the scheduling strategy).
Elevator — has a current floor, a direction (UP/DOWN/IDLE), a state, and a set of target floors (its pending stops).
Request — a source floor + desired direction (external) or a target floor (internal).
Button / Panel — external (per floor) and internal (per car) button panels that generate requests.
Enums: Direction{UP,DOWN,IDLE}, ElevatorState{MOVING,STOPPED,DOORS_OPEN}.

Step 3 — The design

Step 4 — The core: scheduling & movement

🔴 This is where the interview lives — two decisions:

Dispatch (which elevator?): when an external request arrives, the controller picks an elevator via a Strategy: nearest idle, or nearest car already heading that way in the same direction (better). Making this a SchedulingStrategy interface lets you improve the algorithm without touching the controller.
Movement (where next?): each elevator keeps a sorted set of target floors and typically uses the SCAN / "elevator algorithm": keep going in the current direction, stopping at targets, until none remain that way, then reverse. This is efficient and matches how real elevators feel.

class Elevator {
    int currentFloor; Direction dir = IDLE;
    TreeSet<Integer> targets = new TreeSet<>();   // pending stops, sorted
    void addTarget(int floor){ targets.add(floor); }
    void step() {                                    // one tick of movement
        if (targets.isEmpty()) { dir = IDLE; return; }
        int next = (dir == UP) ? targets.higher(currentFloor)
                               : targets.lower(currentFloor);
        // move one floor toward next; on arrival open doors & remove target
    }
}
// controller dispatch:
Elevator best = strategy.chooseElevator(elevators, request);
best.addTarget(request.floor());

Step 5 — State machine

🟠 Each elevator is naturally a State machine: IDLE → MOVING → STOPPED → DOORS_OPEN → (back to MOVING or IDLE). Modelling states explicitly (rather than a tangle of booleans) keeps transitions clear — e.g. you can't move while doors are open. Naming the State pattern here is a strong signal.

Step 6 — The senior nuances

🔴 Mention these: an elevator serving requests in its current direction first (don't zig-zag); handling internal vs external requests uniformly by merging them into the target set; fairness (a request shouldn't starve); and thread-safety if requests arrive concurrently. These show you've thought past the happy path.

The interview-ready walkthrough

"I'd model each Elevator as a state machine (idle/moving/stopped/doors-open) with a sorted set of target floors, moving via the SCAN algorithm — continue in the current direction until no more stops, then reverse. A central Controller dispatches external requests to the best elevator through a pluggable SchedulingStrategy (nearest car heading the same way). Internal and external requests both just add targets. I'd handle direction-first service, fairness, and concurrency." That leads with the scheduling and state-machine core — exactly what's being tested."