Elevator System Design

A step-by-step guide to ace the Elevator System Design interview with hall vs cab calls, practical scheduling, and fair request assignment.

Mar 11, 2026

Elevator system design is a real-time scheduling and control problem that asks you to balance throughput, fairness, rider perception, and physical safety constraints across one or more elevator cars in a building. It is one of the most effective system design interview questions because it forces candidates to structure ambiguity, separate request types, define measurable goals, and evolve a simple controller into a production-grade architecture.

Key takeaways

Request modeling is foundational: Separating hall calls (pickup requests with floor and direction) from cab calls (destination requests inside a specific car) is the single most important modeling decision and a key interview differentiator.
Scheduling is about trade-offs, not a single algorithm: SCAN, LOOK, FCFS, and Nearest Car each optimize for different objectives, and the best answers explain when each policy fits rather than memorizing one.
A scoring model replaces naive heuristics: Assigning hall calls to elevators using a weighted cost function that accounts for ETA, direction compatibility, load, and request age produces tunable, explainable decisions.
Safety and failure handling are non-negotiable: The car controller enforces physical safety locally, and the central scheduler must degrade gracefully when elevators go offline or sensors fail.
Observability closes the loop: Tracking wait-time percentiles, max wait, reversal counts, and utilization per car allows you to detect traffic modes and tune scheduling weights in production.

Every engineer has stood in a lobby, watched three elevators pass by going the wrong direction, and thought “I could design this better.” That confidence is exactly the trap. Elevator system design looks approachable because the domain is familiar, but beneath the surface it is a real-time scheduling problem tangled with control theory, fairness guarantees, and physical constraints that most software engineers never encounter. The question does not test whether you know a single correct algorithm. It tests whether you can define goals under ambiguity, separate concerns cleanly, and evolve a simple design into something production-worthy. This guide walks through every layer of that process, from clarifying requirements through observability and tuning, so you can deliver a Staff-level answer with confidence.

Clarify requirements like a Staff-level candidate#

A strong elevator design answer never starts with “I’ll use SCAN.” It starts with questions. Elevator scheduling is deeply context-dependent, and the same policy that delights residents of a ten-story apartment building can cause five-minute waits in a forty-floor office tower at 9 AM. Interviewers want to see you identify those contextual levers before you commit to any architecture.

Begin with the physical parameters. How many floors? How many elevator cars? Is this a residential building, a commercial office tower, a hospital, or a mixed-use skyscraper? Each building type implies different traffic patterns, peak loads, and rider expectations. A hospital elevator, for example, must support priority calls for patient transport, which most office systems never consider.

Next, clarify the optimization target. The three most common objectives are:

Average wait time: Good for overall throughput but can hide starvation on low-traffic floors.
Worst-case (tail) wait time: Prioritizes fairness and prevents any single rider from waiting unreasonably long.
Predictable response time: Important in buildings where tenants pay for service quality and expect bounded behavior.

You cannot optimize all three simultaneously. State your primary objective and acknowledge the trade-off explicitly. Finally, confirm the interaction model. Traditional systems use hall call buttons (up/down) on each floor. Modern systems use destination dispatchA lobby-based input system where riders enter their destination floor before boarding, allowing the controller to group passengers headed to similar floors into the same car. Destination dispatch fundamentally changes what the scheduler knows at assignment time and unlocks grouping optimizations that traditional hall calls cannot.

Pro tip: In an interview, say this upfront: “Before I pick a scheduling policy, I want to confirm the building type, traffic patterns, and whether we’re optimizing for throughput, fairness, or worst-case wait time.” This single sentence signals structured thinking and buys you room to tailor the design.

The following diagram captures the decision tree a candidate should walk through during requirement clarification.

With goals and constraints anchored, the next step is understanding what kinds of requests the system must handle.

Define the request model with hall calls and cab calls#

A common interview mistake is treating every button press as the same event. In elevator systems, there are two fundamentally different request types, and conflating them leads to muddled logic and missed optimization opportunities.

A hall call originates outside the elevator. A rider presses an up or down button on a floor panel. The system receives a tuple of (floor, direction) but does not know the rider’s final destination (unless destination dispatch is in use). Hall calls represent unserved demand. They are where nearly all scheduling complexity lives because the controller must decide which car should respond, and that decision ripples through wait times for everyone else in the system.

A cab call originates inside a specific elevator car. A rider presses a floor button after boarding. The system receives a destination floor scoped to that car. Cab calls represent committed passengers. The car must honor these stops reliably and in a sensible order. Cab calls are simpler to schedule because the car’s direction and current stop list constrain the options.

Attention: If you skip this distinction in an interview, you will almost certainly conflate “nearest floor” logic for pickups with destination ordering for onboard passengers. That conflation produces a design that sounds reasonable but breaks under any non-trivial traffic scenario.

The separation also matters for state management. Hall calls are global; they live in the central controller’s queue until assigned. Cab calls are local; they live in the specific car’s stop list. When you model these as different data structures with different life cycles, your controller logic becomes cleaner and your failure handling becomes more precise (reassigning a hall call when a car fails is straightforward because the passenger has not boarded yet).

Hall Calls vs. Cab Calls: A Comparative Overview

Dimension	Hall Calls	Cab Calls
Origin	Initiated from the lobby/hallway by waiting passengers	Made from inside the elevator car by passengers
Data Fields	Current floor + desired direction (up/down)	Destination floor + specific elevator car ID
Lifecycle Owner	Central controller assigns to the most suitable elevator	Individual elevator car's control system
Scheduling Complexity	High — requires optimization to minimize wait times	Low — serves requested floors in order received
Failure Handling	Call reassigned to another available elevator	Passengers evacuated and rerouted via other elevators

With request types defined, the next concern is where state lives and how decisions get made, which brings us to the system’s high-level architecture.

High-level architecture and component responsibilities#

Elevator systems are not CRUD applications. They are control systemsArchitectures where a feedback loop continuously reads sensor data, computes decisions based on current state and goals, and issues commands to actuators, repeating this cycle in real time. Treating the problem as a control system rather than a request-response API changes how you think about state, timing, and authority.

At the highest level, the architecture has three layers:

Central scheduler (dispatcher): Receives hall call events, maintains a global view of all car states and pending requests, and decides which car should serve each hall call. It also manages mode detection (rush hour, off-peak, emergency) and adjusts scoring weights accordingly.
Car controller (per elevator): Owns the stop list for its car, manages door operations, motor commands, overload detection, and emergency stops. The car controller is the safety boundaryThe layer of authority beyond which the central scheduler cannot issue commands. If the car controller detects a door obstruction or overload condition, it overrides any instruction from the scheduler.
State store: Maintains a consistent, real-time view of each car’s position, direction, load, door status, and committed stops. The scheduler reads from this store to make assignment decisions.

The following diagram illustrates how these components interact during a typical hall call life cycle.

Real-world context: In production elevator systems made by companies like Otis, Schindler, and ThyssenKrupp, the car controller runs on dedicated embedded hardware with hard real-time guarantees. The central scheduler runs on a separate computing unit (often a PLC or an edge server). This physical separation is not accidental. It ensures that a bug in scheduling logic can never compromise passenger safety.

One important nuance is idempotencyThe property that applying the same command multiple times produces the same result as applying it once. Because the scheduler communicates with car controllers over a network (even if it is a local fieldbus), duplicate or retried messages are possible. Car controllers should treat “add stop at floor 7” as idempotent. If floor 7 is already in the stop list, the command is a no-op.

With components and responsibilities defined, the natural next question is what scheduling policy each car should follow to order its stops.

Elevator scheduling policies and trade-offs#

Scheduling is the heart of the interview. Interviewers are not looking for a single correct algorithm. They are testing whether you can explain multiple policies, articulate when each one fits, and handle pushback by extending your model rather than abandoning it.

Directional scanning with SCAN and LOOK#

The strongest baseline is directional scanning. An elevator continues in its current direction, serving all requests along the way, then reverses when no more requests remain in that direction. This approach minimizes unnecessary reversals and feels intuitive to riders because the car behaves predictably.

Two classic variants exist. SCAN (sometimes called the elevator algorithm, borrowing terminology from disk I/O scheduling) travels all the way to the last floor in a direction before reversing, even if no requests exist beyond the last served stop. LOOK is smarter. It reverses as soon as there are no pending requests ahead. LOOK wastes less time and is the practical default in most real implementations.

Historical note: The SCAN algorithm was originally formalized for disk arm scheduling in operating systems. The analogy is direct. A disk arm moving across platters to serve read/write requests faces the same “minimize seek time” problem as an elevator serving floor requests. The name “elevator algorithm” in OS textbooks comes from this connection.

FCFS and its limitations#

First-Come, First-Served is the simplest possible policy. Serve requests in the order they arrive. It is fair in a strict temporal sense but produces terrible real-world behavior. An elevator might reverse direction repeatedly, bouncing between floors, because the next request in the queue happens to be in the opposite direction. FCFS is useful as a conceptual baseline to explain why directional policies exist, but it should never be your final answer.

Nearest Car and its hidden costs#

“Assign the nearest elevator” is a common first instinct. It works acceptably when traffic is light and symmetric, but it breaks down under load. An elevator one floor away but moving in the opposite direction will take longer to arrive than one three floors away moving toward the request. Nearest Car ignores direction, load, and existing commitments. Use it only as a starting point to motivate a richer scoring model.

The following table compares the key scheduling policies across several dimensions.

Comparison of Elevator Scheduling Algorithms

Parameter	FCFS	SCAN	LOOK	Nearest Car
Average Wait Time	High – no seek optimization	Moderate – minimizes unnecessary movement	Low-Moderate – reverses before end if no requests remain	Lowest – assigns closest available elevator
Worst-Case Wait Time	High – unpredictable under heavy load	Moderate – predictable, services one direction fully	Moderate-Low – avoids unnecessary end travel	Low – dynamic assignment, though varies with availability
Fairness	Highest – strict arrival order	Moderate – end-floor requests may wait longer	Moderate – slight improvement over SCAN	Variable – nearby requests prioritized; others may be delayed
Implementation Complexity	Low – simple queue management	Moderate – requires direction tracking	Moderate-High – must detect last request in current direction	High – real-time multi-elevator tracking and dynamic assignment
Best-Fit Building Type	Small buildings, low traffic	Medium buildings, moderate traffic	Medium to large buildings, efficiency-focused	Large buildings, high traffic, multiple elevators

Batching for peak traffic#

During rush hours, throughput matters more than individual fairness. BatchingA scheduling strategy that groups multiple requests headed in the same direction into a single sweep, reducing the number of stops and direction reversals per trip. In up-peak mode (morning office arrival), the controller pre-positions cars at the lobby, fills each car with riders headed to a range of upper floors, and runs a LOOK sweep upward. Batching dramatically improves throughput but can temporarily disadvantage riders on mid-floors trying to go down.

Aging to prevent starvation#

Any throughput-optimized policy risks starvationA condition where a request waits indefinitely (or unreasonably long) because the scheduler continuously prioritizes other, seemingly more efficient requests. The solution is aging. Every unserved hall call accumulates a priority bonus proportional to how long it has been waiting. Eventually, even a low-priority request on a quiet floor becomes the highest-priority item in the system. Aging is the mechanism that turns a throughput-focused scheduler into a fair one.

Pro tip: In an interview, say: “I’ll start with LOOK for predictable routing, add aging to prevent starvation, and layer on batching for peak traffic.” This three-part statement covers baseline behavior, fairness, and performance in a single sentence.

With scheduling policies defined for individual cars, the next challenge is deciding which car should respond to a given hall call in the first place.

Request assignment logic with a scoring model#

Choosing which elevator serves a hall call is the multi-elevator coordination problem, and it is where many candidates plateau. “Pick the nearest elevator” is a one-dimensional heuristic that collapses under realistic conditions. A car that is one floor away but fully loaded and committed to six stops is a worse choice than a car three floors away, moving in the right direction, with an empty queue.

Building the cost function#

A Staff-level answer introduces a scoring model. For each pending hall call, evaluate every eligible elevator and compute a cost. The elevator with the lowest cost wins the assignment. The cost function should capture several dimensions:

$$\\text{score}(e, r) = w1 \\cdot \\text{ETA}(e, r) + w2 \\cdot D{\\text{penalty}}(e, r) + w3 \\cdot S{\\text{count}}(e) + w4 \\cdot L{\\text{ratio}}(e) - w5 \\cdot \\text{age}(r)$$

Where:

$\\text{ETA}(e, r)$ is the estimated time for elevator $e$ to reach request $r$’s floor given its current trajectory.
$D_{\\text{penalty}}(e, r)$ penalizes direction mismatch (e.g., the car is moving away from the request).
$S_{\\text{count}}(e)$ reflects the number of committed stops, capturing how “busy” the car is.
$L_{\\text{ratio}}(e)$ is the current load as a fraction of capacity.
$\\text{age}(r)$ is how long the request has been waiting, entered as a negative bonus so older requests become more attractive.

The weights $w1$ through $w5$ are tunable parameters. This is the key architectural advantage. When the interviewer asks “What about fairness?” you increase $w_5$. When they ask “What about energy?” you add a movement-distance penalty term. When they ask “What about rush hour?” you shift weights dynamically based on detected traffic mode.

Python

from dataclasses import dataclass
from typing import List, Optional
@dataclass
class Elevator:
    id: int
    current_floor: int
    direction: int          # 1 = up, -1 = down, 0 = idle
    load: int               # number of passengers currently aboard
    capacity: int           # maximum passenger capacity
@dataclass
class HallCall:
    floor: int
    direction: int          # 1 = up, -1 = down
# Weight constants for normal mode
WEIGHT_DISTANCE_NORMAL   = 1.0
WEIGHT_LOAD_NORMAL       = 0.5
WEIGHT_DIRECTION_NORMAL  = 0.8
# Weight constants for up-peak mode (favor lightly loaded cars moving upward)
WEIGHT_DISTANCE_UPPEAK   = 0.6
WEIGHT_LOAD_UPPEAK       = 1.5   # penalize high load more aggressively
WEIGHT_DIRECTION_UPPEAK  = 0.3   # direction alignment matters less during up-peak
def compute_score(
    elevator: Elevator,
    call: HallCall,
    w_distance: float,
    w_load: float,
    w_direction: float,
) -> float:
    """Compute weighted cost for assigning this elevator to the hall call."""
    # Distance component: floors between elevator and call floor
    distance = abs(elevator.current_floor - call.floor)
    # Load ratio: fraction of capacity already used (0.0 – 1.0)
    load_ratio = elevator.load / elevator.capacity if elevator.capacity > 0 else 1.0
    # Direction penalty: 0 if elevator moves toward call in matching direction, else 1
    moving_toward = (
        (call.floor > elevator.current_floor and elevator.direction == 1) or
        (call.floor < elevator.current_floor and elevator.direction == -1) or
        elevator.direction == 0  # idle elevators have no penalty
    )
    direction_mismatch = 0.0 if moving_toward else 1.0
    score = (
        w_distance  * distance        +   # travel cost
        w_load      * load_ratio      +   # congestion cost
        w_direction * direction_mismatch  # direction alignment cost
    )
    return score
def select_elevator(
    elevators: List[Elevator],
    call: HallCall,
    up_peak_mode: bool = False,
) -> Optional[Elevator]:
    """
    Iterate over candidate elevators, compute weighted score for the hall call,
    and return the elevator with the minimum cost.
    Weights are adjusted based on whether up-peak mode is active.
    """
    if not elevators:
        return None
    # Choose weight set based on traffic mode
    if up_peak_mode:
        w_distance  = WEIGHT_DISTANCE_UPPEAK
        w_load      = WEIGHT_LOAD_UPPEAK
        w_direction = WEIGHT_DIRECTION_UPPEAK
    else:
        w_distance  = WEIGHT_DISTANCE_NORMAL
        w_load      = WEIGHT_LOAD_NORMAL
        w_direction = WEIGHT_DIRECTION_NORMAL
    best_elevator: Optional[Elevator] = None
    best_score = float("inf")
    for elevator in elevators:
        # Skip elevators that are already at full capacity
        if elevator.load >= elevator.capacity:
            continue
        score = compute_score(elevator, call, w_distance, w_load, w_direction)
        if score < best_score:   # track the minimum-cost candidate
            best_score    = score
            best_elevator = elevator
    return best_elevator

Real-world context: Modern elevator systems from companies like KONE and Otis use proprietary variants of scoring-based dispatching. KONE’s destination dispatch system (branded as “KONE Destination”) groups riders at the lobby panel and assigns cars using optimization algorithms that are conceptually similar to the weighted scoring model described here.

Handling reassignment#

Assignments are not permanent. If a car becomes unavailable (doors stuck, overload, mechanical fault), the system must re-queue the hall call and rerun assignment for a different car. Because hall calls are modeled separately from cab calls and live in the central scheduler’s queue, this reassignment is straightforward. The state store marks the car as unavailable, and the next scoring cycle picks a new winner.

A subtle concern is plan churnExcessive reassignment of hall calls or reordering of stops that causes riders to experience unpredictable elevator behavior, such as a car appearing to "change its mind" about which floor it will visit next. To avoid plan churn, only reassign a hall call if the cost improvement exceeds a threshold or if the originally assigned car’s status has genuinely changed.

Let us now see how these policies and scoring models behave in concrete scenarios, starting with the most common challenge in office buildings.

Walk-through 1: office rush hour traffic (up-peak)#

Office buildings exhibit a sharp, predictable pattern. Between 8:00 and 9:30 AM, a large volume of riders arrive at the lobby and need to go up. The lobby becomes a bottleneck. If the system treats every hall call with equal priority, lobby wait times explode while upper-floor down calls get served quickly by cars that should be cycling back to the lobby.

In up-peak mode, the controller makes three strategic shifts:

Pre-positioning: Idle cars return to the lobby rather than parking at their last served floor. This reduces pickup latency for the dominant demand source.
Directional batching: Each car fills at the lobby and runs a LOOK sweep upward, serving all cab calls in ascending order before returning empty. Cars do not stop for downward hall calls on intermediate floors during the sweep.
Aging for fairness: Down calls from upper floors are temporarily deprioritized but not ignored. The aging term in the scoring function ensures that any down call waiting beyond a configured threshold gets served, even during peak mode.

If destination dispatch is available, up-peak mode becomes significantly more powerful. The lobby panel collects destination floors before boarding, and the controller groups riders headed to similar floor ranges into the same car. This reduces the number of stops per sweep and increases throughput by 20 to 30 percent compared to traditional hall call systems, according to research published by elevator engineering groups.

Attention: Do not claim that batching “solves” rush hour. Batching improves throughput at the cost of fairness. If you do not mention aging or a max-wait cap alongside batching, an interviewer will rightly push back that your system starves minority traffic patterns.

The up-peak scenario is relatively clean because traffic is almost entirely unidirectional. The harder case is mid-day mixed traffic, where fairness controls do the real work.

Walk-through 2: mixed traffic with fairness concerns#

At mid-day, traffic patterns become chaotic. Riders move between arbitrary floors in both directions. Some floors generate heavy inter-floor traffic (cafeteria floor, meeting room floors), while others are nearly silent. A purely directional policy can inadvertently starve quiet floors because elevators keep getting pulled toward high-demand clusters.

This scenario exercises three design elements simultaneously:

Aging: A hall call on a quiet floor may not be “optimal” to serve immediately. But as its age grows, the negative bonus in the scoring function increases until some car finds it cheapest to detour. This guarantees bounded worst-case wait time even for low-traffic floors.
Load balancing across cars: If all three elevators cluster near the cafeteria floor because that is where demand is highest, distant floors suffer. The scoring function’s stop-count penalty ($w3 \\cdot S{\\text{count}}$) spreads load by making heavily committed cars less attractive for new assignments.
Plan stability: Riders dislike unpredictability. If a car’s stop list changes frequently because the scheduler keeps inserting “more optimal” stops, riders experience the car seemingly skipping or revisiting floors. The plan-churn threshold prevents this by only allowing new stop insertions that are either “on the way” (zero additional travel cost) or that cross a minimum cost-improvement threshold.

Real-world context: The perception of fairness often matters more than actual fairness. A rider who waits 90 seconds on a quiet floor but sees the elevator arrive “for them” feels better served than a rider who waits 60 seconds but watches two cars pass by going the wrong direction. This is why plan stability and predictable directional behavior are product-level concerns, not just engineering details.

Mixed traffic is also where simple metrics fail. Average wait time might look excellent while a handful of floors experience three-minute waits. This is why you must track tail latency (p95 and p99 wait time) alongside averages, a point we will revisit in the observability section.

Before scaling the architecture, we need to address what happens when things go wrong.

Failure and safety thinking#

Elevator systems are cyber-physical systemsSystems where computational algorithms directly control physical processes, and failures in either domain can affect the other. A bug in scheduling logic could theoretically send a car to a floor where doors should not open, and a stuck door sensor can prevent a car from moving regardless of what the scheduler commands. This dual nature means safety constraints dominate every other design consideration.

The cardinal rule is that the car controller, not the central scheduler, is the ultimate authority on motion and door operations. If the car controller detects an overload, it refuses to move. If a door sensor reports an obstruction, the doors remain open regardless of scheduling pressure. If an emergency stop is triggered, the car halts and the scheduler is notified after the fact. The scheduler’s role is to optimize service. The car controller’s role is to guarantee safety. These two responsibilities must never be merged.

Failure scenarios to discuss in an interview include:

Car goes offline: The scheduler detects a missed heartbeat, marks the car as unavailable, and re-queues all hall calls that were assigned to it. Cab call passengers are informed through in-car displays and intercom.
Sensor failure: If floor-position sensors fail, the car controller cannot confirm its location. It must stop and report an error rather than guessing. The scheduler removes the car from the eligible pool.
State store inconsistency: If the state store temporarily lags behind reality (e.g., a car has moved but the store still shows its old position), the scheduler should prefer conservative decisions. Assigning a call to a car whose state is stale is better than issuing conflicting commands to two cars.

Attention: Ignoring failure modes because “it’s just an interview” is a missed opportunity. Real elevator systems spend more engineering effort on failure handling than on scheduling optimization. Mentioning graceful degradation (the system continues with reduced capacity when a car fails) is a strong signal of production thinking.

With failure handling covered, the next concern is what happens when the building outgrows a single central scheduler.

Scaling from centralized to hierarchical and zoned control#

A centralized scheduler works well for buildings with up to roughly 8 to 12 elevators and 30 to 40 floors. It maintains global state, makes globally optimal assignments, and the computational cost of scoring all (elevator, request) pairs is negligible at that scale. But as buildings get taller, the centralized model hits two limits.

First, traffic patterns become localized. In a 60-floor skyscraper, riders on floors 1 through 20 have almost no interaction with riders on floors 40 through 60. Running a global scoring function across all cars for every request wastes computation and can produce worse outcomes because distant cars score artificially well on certain metrics (e.g., low load) despite being physically irrelevant.

Second, the state store becomes a coordination bottleneck. With 20+ cars reporting telemetry multiple times per second, a single store can experience contention. Partitioning state by zone eliminates this bottleneck.

The standard evolution is zoning with hierarchical control:

Zones: Partition the building into low-rise (floors 1–20), mid-rise (21–40), and high-rise (41–60). Assign dedicated elevator groups to each zone. Express elevators skip zones entirely.
Zone controllers: Each zone runs its own scheduler, managing only the cars and requests within its range. This reduces the scoring space and allows zone-specific tuning (e.g., the lobby zone can run up-peak mode while the high-rise zone runs mixed-traffic mode).
Coordinator: A lightweight higher-level process handles cross-zone concerns like mode switching, service elevator routing, and rebalancing cars between zones during demand shifts.

Centralized vs. Zoned Architecture Comparison

Criteria	Centralized Architecture	Zoned Architecture
State Complexity	High; monolithic structure with tightly coupled, collectively managed state	Lower; isolated states per zone improve modularity and manageability
Scoring Computation Cost	Higher; single processing point creates bottlenecks and increased latency	Lower; distributed processing across zones reduces load and improves efficiency
Failure Blast Radius	Large; a single failure can cascade and impact the entire system	Contained; failures are isolated within a zone, preserving overall system stability
Tuning Granularity	Coarse; intertwined components make adjustments risky and far-reaching	Fine; each zone can be independently optimized without affecting others
Implementation Effort	Lower upfront; simpler initially but grows complex and harder to scale over time	Higher upfront; requires careful zone boundary design but yields long-term scalability

Pro tip: In interviews, present this as an evolution, not a starting point. Say: “I’ll design a centralized controller first because it’s simpler and globally optimal for small buildings. For taller buildings, I’d partition into zones with local schedulers and a lightweight coordinator.” This progression demonstrates that you can design an MVP and scale it.

Zoning also improves failure isolation. If the mid-rise zone controller crashes, the low-rise and high-rise zones continue operating independently. Only cross-zone traffic is affected, and the coordinator can reroute those requests to adjacent zones as a fallback.

Architecture decisions are only as good as your ability to measure their outcomes. The final layer of a production-grade elevator system is observability and tuning.

Observability, metrics, and production tuning#

An elevator scheduling system is not “deploy and forget.” The scoring weights, batching thresholds, and mode-detection rules that work during commissioning may drift as tenant behavior changes, building occupancy shifts, or new floors open. Observability is how you close the feedback loop between design intent and real-world performance.

Rider-centric metrics#

The metrics that matter most are the ones riders feel:

Wait time percentiles (p50, p95, p99): p50 tells you typical experience. p95 and p99 reveal starvation and tail-latency problems that averages hide.
Travel time: Time from boarding to arriving at the destination floor. Excessive stops degrade this metric.
Stop count per trip: Fewer stops mean faster trips. This metric is especially useful for evaluating batching effectiveness.

System-centric metrics#

Operational health requires a different lens:

Utilization per car: Identifies imbalanced load distribution. If one car is at 90% utilization while another is at 20%, the scoring model needs rebalancing.
Direction reversals per hour: High reversal rates indicate the scheduling policy is thrashing rather than scanning smoothly.
Reassignment rate: How often hall calls are reassigned to a different car after initial assignment. High rates signal instability in the scoring model or frequent car failures.
Max wait time: The single longest wait across all floors in a time window. This is your starvation canary.

The tuning loop#

Production tuning follows a detect-adjust-validate cycle:

Detect traffic mode: Use arrival rate patterns to classify the current period as up-peak, down-peak, mixed, or low-traffic.
Adjust parameters: Shift scoring weights (increase $w5$ for fairness during mixed mode, increase $w1$ for speed during peak mode), change batching thresholds, and toggle pre-positioning behavior.
Validate: Use shadow evaluation, a technique where you replay recorded request traces through a candidate configuration and compare predicted outcomes against the current production policy before switching live traffic.

Historical note: Early elevator systems from the 1970s and 1980s used fixed scheduling tables tuned by building engineers during installation. Modern systems from ThyssenKrupp (now TK Elevator) and Mitsubishi Electric use adaptive algorithms that continuously retune based on real-time telemetry, a shift enabled by cheap embedded computing and persistent storage in car controllers.

With observability in place, the design is complete end to end. Let us consolidate the interview delivery strategy before closing.

How to structure your interview answer#

The biggest risk in an elevator design interview is not getting the algorithm wrong. It is losing control of the conversation. If you jump into SCAN or LOOK without framing the problem, the interviewer will steer you into corners you are not prepared for. Structure is your defense.

Deliver the answer in this order:

Clarify requirements: Building type, scale, traffic patterns, optimization target, interaction model.
Define the request model: Hall calls vs. cab calls, their data shapes, and their life cycle owners.
Propose architecture: Central scheduler, car controllers, state store, safety boundary.
Explain scheduling policy: LOOK as baseline, batching for peaks, aging for fairness.
Describe assignment logic: Scoring model with tunable weights.
Walk through scenarios: Up-peak, mixed traffic.
Cover failure handling: Car offline, sensor failure, graceful degradation.
Scale the architecture: Zoning and hierarchical control for tall buildings.
Close with observability: Metrics, tuning loop, shadow evaluation.

When the interviewer challenges your approach, respond by extending your model. If they ask about fairness, add the aging term. If they ask about energy efficiency, add a movement-distance penalty. If they ask about VIP floors, add a priority multiplier. The scoring model is deliberately extensible, and that composability is the design’s greatest strength.

Pro tip: Practice saying this transition: “That’s a great constraint. Let me show how I’d extend the scoring model to handle it.” This phrase keeps you in control and demonstrates that your architecture absorbs new requirements without being redesigned from scratch.

Common mistakes to avoid#

Even well-prepared candidates stumble on predictable pitfalls. Knowing what not to do is as valuable as knowing what to do.

Skipping the request model: Jumping into scheduling without separating hall calls from cab calls produces muddled state management and makes failure handling nearly impossible to reason about.
Optimizing only for average wait time: Average wait is a vanity metric that hides starvation. Always pair it with p95/p99 wait and max wait. If you cannot explain how your design bounds worst-case behavior, the interviewer will find the hole.
Over-engineering early: Proposing a machine-learning-based scheduler or a distributed consensus protocol before you have defined the basic request flow signals that you are pattern-matching from other interviews rather than reasoning about this specific problem.
Ignoring the physical layer: The car controller is not an abstraction you can hand-wave away. Acknowledging that the scheduler cannot override safety constraints is a one-sentence addition that dramatically improves your answer’s credibility.
Treating scheduling as the entire problem: Scheduling is one layer. Request modeling, architecture, assignment, failure handling, scaling, and observability are equally important layers. The best answers cover breadth with selective depth.

Python

import time
import logging
from dataclasses import dataclass, field
from typing import Optional
from enum import Enum, auto
logger = logging.getLogger(__name__)
class CallState(Enum):
    PENDING    = auto()
    ASSIGNED   = auto()
    PICKED_UP  = auto()
    COMPLETED  = auto()
    REASSIGNED = auto()
@dataclass
class HallCall:
    call_id: str
    origin_floor: int
    direction: str          # "UP" or "DOWN"
    arrival_time: float = field(default_factory=time.monotonic)
    state: CallState = CallState.PENDING
    assigned_car_id: Optional[str] = None
    pickup_time: Optional[float] = None
    completion_time: Optional[float] = None
@dataclass
class Elevator:
    car_id: str
    current_floor: int
    direction: str          # "UP", "DOWN", or "IDLE"
    stop_list: list = field(default_factory=list)
    online: bool = True
# ---------------------------------------------------------------------------
# Scoring
# ---------------------------------------------------------------------------
def score_candidate(car: Elevator, call: HallCall) -> float:
    """
    Lower score = better candidate.
    Factors: floor distance, direction alignment, stop-list length.
    """
    distance = abs(car.current_floor - call.origin_floor)
    # Penalise cars moving away from or opposite to the call direction
    direction_penalty = 0
    if car.direction != "IDLE" and car.direction != call.direction:
        direction_penalty = 10
    # Light penalty for already-busy cars
    load_penalty = len(car.stop_list) * 0.5
    return distance + direction_penalty + load_penalty
def select_best_car(cars: list[Elevator], call: HallCall) -> Optional[Elevator]:
    """Return the online car with the lowest score, or None if none available."""
    candidates = [c for c in cars if c.online]
    if not candidates:
        return None
    return min(candidates, key=lambda c: score_candidate(c, call))
# ---------------------------------------------------------------------------
# Assignment helpers
# ---------------------------------------------------------------------------
def assign_call(call: HallCall, car: Elevator) -> None:
    """Attach the call to the car's stop list and update call state."""
    call.assigned_car_id = car.car_id
    call.state = CallState.ASSIGNED
    if call.origin_floor not in car.stop_list:
        car.stop_list.append(call.origin_floor)
        car.stop_list.sort()                    # keep stops ordered for dispatch
    logger.info("Call %s assigned to car %s (stop list: %s)",
                call.call_id, car.car_id, car.stop_list)
def remove_call_from_car(call: HallCall, car: Elevator) -> None:
    """Remove the call's floor from the car's stop list on reassignment."""
    if call.origin_floor in car.stop_list:
        car.stop_list.remove(call.origin_floor)
# ---------------------------------------------------------------------------
# Metrics
# ---------------------------------------------------------------------------
def emit_metrics(call: HallCall) -> None:
    """Publish completion metrics (hook into your telemetry system here)."""
    wait_time    = (call.pickup_time or 0) - call.arrival_time
    journey_time = (call.completion_time or 0) - (call.pickup_time or 0)
    total_time   = (call.completion_time or 0) - call.arrival_time
    logger.info(
        "METRICS | call=%s car=%s state=%s "
        "wait=%.2fs journey=%.2fs total=%.2fs",
        call.call_id, call.assigned_car_id, call.state.name,
        wait_time, journey_time, total_time,
    )
    # emit_to_monitoring_system(call.call_id, wait_time, journey_time, total_time)
# ---------------------------------------------------------------------------
# Core lifecycle
# ---------------------------------------------------------------------------
def process_hall_call(call: HallCall, cars: list[Elevator]) -> None:
    """
    Execute the complete hall-call lifecycle:
      1. Arrive at scheduler
      2. Score candidates and assign
      3. Simulate pickup
      4. Reassign if assigned car goes offline before pickup
      5. Log completion and emit metrics
    """
    # ── 1. Arrival ──────────────────────────────────────────────────────────
    logger.info("Hall call %s arrived: floor=%d dir=%s",
                call.call_id, call.origin_floor, call.direction)
    # ── 2. Initial assignment ────────────────────────────────────────────────
    best_car = select_best_car(cars, call)
    if best_car is None:
        logger.error("No available cars for call %s. Queuing for retry.", call.call_id)
        return                                  # real system would enqueue and retry
    assign_call(call, best_car)
    # ── 3. Wait for pickup (simulate car travel; check for car failure) ──────
    assigned_car = best_car
    pickup_achieved = False
    for _ in range(10):                         # polling loop; replace with event-driven logic
        time.sleep(0.05)                        # simulated tick
        # ── 3a. Reassignment branch: assigned car went offline ───────────────
        if not assigned_car.online:
            logger.warning(
                "Car %s went offline before picking up call %s. Reassigning.",
                assigned_car.car_id, call.call_id,
            )
            remove_call_from_car(call, assigned_car)
            call.state = CallState.REASSIGNED
            new_car = select_best_car(cars, call)
            if new_car is None:
                logger.error("Reassignment failed for call %s: no cars available.", call.call_id)
                return
            assign_call(call, new_car)
            assigned_car = new_car              # track the newly assigned car
        # ── 3b. Check whether the car has reached the pickup floor ───────────
        if assigned_car.current_floor == call.origin_floor:
            call.pickup_time = time.monotonic()
            call.state = CallState.PICKED_UP
            logger.info("Call %s picked up by car %s at floor %d",
                        call.call_id, assigned_car.car_id, call.origin_floor)
            pickup_achieved = True
            break
    if not pickup_achieved:
        logger.error("Call %s was not picked up within the polling window.", call.call_id)
        return
    # ── 4. Simulate ride to destination (destination floor handled separately) ─
    time.sleep(0.05)                            # placeholder for in-car travel simulation
    # ── 5. Completion ────────────────────────────────────────────────────────
    call.completion_time = time.monotonic()
    call.state = CallState.COMPLETED
    logger.info("Call %s completed by car %s.", call.call_id, assigned_car.car_id)
    emit_metrics(call)

Conclusion#

Elevator system design rewards the candidate who structures ambiguity rather than the one who memorizes algorithms. The most critical decisions are not about SCAN vs. LOOK. They are about separating hall calls from cab calls so your state model is clean, building a scoring-based assignment function so your decisions are tunable and explainable, and layering aging, batching, and zoning onto a simple baseline so the design evolves gracefully under pressure. These three moves (request modeling, scoring-based assignment, and incremental sophistication) are what interviewers associate with senior and Staff-level thinking.

Looking ahead, elevator systems are increasingly influenced by IoT telemetry, predictive traffic modeling using building access-card data, and integration with smart-building platforms that coordinate elevators with HVAC, lighting, and security systems. The scoring model you design today is the foundation for adaptive, data-driven scheduling tomorrow.

Design for clarity first, optimize for throughput second, and never forget that the person waiting on floor 14 deserves a bounded wait time. That principle will serve you in the interview and in production.

Written By:

Khayyam Hashmi

Free Resources

blog

Why is feature scaling needed in Machine Learning

blog

What is AWS and how to get started

blog

Most in-demand skills for Node.js developer roles