Elevator System Design

Designing an elevator system is one of those interview questions that feels familiar enough to be easy—and that’s exactly why it’s deceptively powerful. Everyone has ridden elevators. Everyone has opinions about what “good” looks like. But under the hood, you’re building a real-time scheduling system that balances throughput, fairness, human perception of waiting, and physical constraints.

This problem is also a great system design interview signal because it forces you to structure ambiguity. You’re not just picking an algorithm. You’re defining goals, separating request types, designing state and control loops, and explaining how the system evolves from a simple centralized controller to a scalable, production-tuned system.

Interview signal: Elevator design isn’t a “data structures” question. It’s a scheduling + control + product trade-off question. The best answers start with goals and constraints, not algorithms.

In this blog, you’ll learn how to deliver an interview-ready elevator design: clarify requirements, define request models, design a controller, choose scheduling policies, build request assignment logic, handle failures, scale the architecture, and close with observability and tuning.

Clarify requirements like a Staff-level candidate#

A strong elevator system design answer begins with deliberate clarifying questions. Not because you’re stalling, but because elevator scheduling is highly dependent on context. The same policy that feels great in a quiet residential building can perform terribly in an office tower during rush hour. Interviewers want to see you identify those constraints early and anchor your design to them.

Start by clarifying the environment: number of floors, number of elevators, building type, and traffic patterns. Then clarify what “good” means. Is the priority average wait time, worst-case wait time, fairness across floors, or predictable response time? You can’t optimize everything at once, so you need to choose a primary objective and explicitly state the trade-off.

Finally, clarify what level of complexity is expected. Some interviewers want a single-building controller; others want a multi-zone system for skyscrapers. If you state a reasonable baseline and offer an evolution path, you’ll satisfy both.

What to say in the interview: “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.”

Summary (after the explanation):

• Ask about building type, scale, and traffic patterns.

• Define what success means (average vs tail wait vs fairness).

• Confirm the interaction model (traditional vs destination dispatch).

Define the request model: hall calls vs cab calls#

A common interview mistake is treating every button press as the same kind of request. In elevator systems, there are two fundamentally different request types, and separating them makes your design clearer and more correct.

A hall call is made outside the elevator: it includes a floor and a direction (up/down). It does not include the final destination. A hall call is a request for service: “pick me up going up.” A cab call is made inside the elevator: it includes a destination floor and is tied to a specific elevator car. Cab calls represent committed passengers already onboard.

This distinction matters because hall calls are where most scheduling complexity lives. You need to decide which elevator should respond, and you want to do that in a way that reduces waiting and avoids starvation. Cab calls are simpler: once a passenger is inside, the elevator must serve those destinations reliably and predictably.

Interview signal: Explicitly separating hall calls and cab calls is a strong sign you understand the problem space. It’s a common differentiator in interviews.

Summary (after the explanation):

• Hall calls are pickup requests (floor + direction).

• Cab calls are destination requests inside a specific elevator.

• Most optimization is in hall call assignment.

High-level architecture: components and responsibilities#

Once the request model is clear, the next step is describing responsibilities. Interviewers want a system that can accept events (button presses), maintain state (elevator positions and commitments), and make decisions (assignments and stop order). This is a control system, not a CRUD app.

At a baseline, you can model the system as a centralized controller that receives events from floors and elevators, maintains a global view of state, and produces commands. That controller doesn’t physically move the elevator—it sends target stop lists or next-stop instructions to each car controller.

Each elevator has its own local controller responsible for safe motion: door operations, motor control, overload detection, emergency stops. In interviews, you don’t need to design motor firmware, but you should acknowledge that the local controller is the safety boundary and the central scheduler cannot override safety constraints.

Common pitfall: Jumping straight into “use SCAN” without defining where state lives and how decisions get applied. Architecture first, policy second.

Summary (after the explanation):

• Central controller assigns hall calls and plans stops.

• Car controllers execute motion safely and report telemetry.

• State store keeps a consistent view of elevator status and queues.

Elevator scheduling policies and trade-offs#

Scheduling is where interviewers push. They’re not testing whether you memorized a single “correct” algorithm—they’re testing whether you can explain trade-offs and pick a policy that matches the building’s needs.

A solid baseline policy is directional scanning: an elevator continues in its current direction serving requests along the way, then reverses when there’s nothing left in that direction. This reduces wasted movement and is intuitive for riders because it avoids constant route changes. SCAN and LOOK are the classic variants: SCAN goes to the end before reversing, LOOK reverses once no more requests exist ahead.

Batching is another key concept. During rush hour, you want to group service by direction and reduce stops. For example, you can bias elevators to “up-peak mode” in the morning: prioritize upward hall calls in the lobby and serve higher floors in a single sweep. But batching introduces fairness concerns: if you over-optimize for throughput, people on low-traffic floors can wait too long.

That’s where fairness and starvation prevention come in. A Staff-level answer explicitly mentions aging: hall calls gain priority the longer they wait. This prevents “the system looks efficient on average but feels unfair.”

What to say in the interview: “I’ll start with LOOK/SCAN for predictable routing, then add aging to prevent starvation and batching for peak traffic.”

Summary (after the explanation):

• SCAN/LOOK are strong baselines for predictable behavior.

• Batching improves throughput during peak traffic.

• Aging prevents starvation and improves perceived fairness.

Request assignment logic (choosing the best elevator)#

Once you have scheduling inside each elevator, you still need to decide which elevator should pick up a hall call. This is where many candidates hand-wave with “pick the nearest elevator,” which breaks down quickly. Nearest by distance is often the wrong choice if the elevator is moving the opposite direction, overloaded, or already committed to many stops.

A strong interview answer uses a scoring model. For each hall call, evaluate candidate elevators and compute a cost score. Lower score wins. The score should reflect estimated pickup time, direction compatibility, current load, stop commitments, and fairness. This gives you a structured, explainable assignment policy that you can tune.

The scoring model is also how you handle pushback. If the interviewer says “what about fairness?” you add an aging term. If they say “what about energy?” you add a movement penalty. If they say “what about rush hour?” you adjust weights dynamically based on traffic mode.

Interview signal: A scoring-based assignment model is a strong “systems thinker” move. It turns a vague heuristic into something measurable and tunable.

Example scoring formula (interview-friendly)#

You don’t need heavy math, but you should show structure:

score(elevator, request) =
w1 · ETA_to_pickup + w2 · direction_penalty + w3 · stop_penalty + w4 · load_penalty − w5 · request_age_bonus

The negative age bonus means older requests become more attractive to serve.

Summary (after the explanation):

• Avoid “nearest elevator” as a single rule.

• Use a scoring model that balances ETA, direction, load, and fairness.

• Tune weights based on traffic patterns (rush hour vs normal).

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

Office buildings have a predictable pattern: in the morning, many people arrive at the lobby and go up. The system’s goal shifts from fairness across floors to throughput and fast pickup at the lobby. If you treat every hall call equally, the lobby becomes congested and wait times explode.

In up-peak mode, the controller can pre-position elevators at the lobby and batch upward trips. For example, assign an elevator to serve a range of destination floors or simply let it fill and then run a LOOK sweep upward. Hall calls from upper floors going down are deprioritized temporarily but not ignored—aging ensures they still get served.

This is also where destination dispatch (if available) changes the game. If riders enter their destination on the lobby panel, the controller can group riders going to similar floors, reducing stops and improving throughput dramatically. If you don’t have destination dispatch, you still get batching benefits by biasing assignments toward elevators already heading up and minimizing reversals.

What to say in the interview: “During up-peak, I switch the system into a mode that prioritizes lobby pickup throughput, batches upward trips, and uses aging so down calls don’t starve.”

Summary (after the explanation):

• Detect up-peak traffic and enable batching.

• Pre-position cars at the lobby and run directional sweeps.

• Use aging to preserve fairness for non-peak requests.

Walkthrough 2: mixed up/down traffic with fairness concerns#

Mixed traffic is the harder case because both directions matter at the same time. Imagine a mid-day scenario: people are moving between floors, some are going up, some are going down, and a few floors generate more traffic than others. A naive directional policy can accidentally starve certain hall calls, especially if elevators keep getting pulled toward high-traffic floors.

This is where your scoring model and fairness terms do real work. When a hall call arrives on a low-traffic floor, it might not be “optimal” to serve immediately. But if it waits too long, the system should increase its priority. That’s the aging term in your assignment score, and it’s what makes the system feel fair.

You also need to handle route stability. Riders dislike elevators that constantly change direction or skip expected stops. So even though dynamic rerouting can reduce average wait time, you should avoid excessive plan churn. A good rule is to only insert new stops if they are “on the way” or if the cost improvement crosses a threshold.

If the interviewer pushes back: “If we optimize purely for average wait time, some floors can starve. I prevent that with aging and a cap on maximum wait time, even if it slightly reduces throughput.”

Summary (after the explanation):

• Mixed traffic requires fairness controls, not just directional routing.

• Aging prevents starvation and improves perceived quality.

• Avoid excessive rerouting; maintain plan stability.

Failure and safety thinking (high level)#

Elevator systems are cyber-physical. That means safety constraints dominate. In interviews, you don’t need to implement safety logic, but you must show awareness of what happens when things go wrong: stuck doors, overload, elevator offline, sensor failures, and emergency stops.

The key design principle is that the central scheduler is not the ultimate authority. The car controller enforces safety rules locally. If doors are stuck, the elevator can’t move. If overloaded, it can’t accept more passengers. If an elevator goes offline, the system must reassign hall calls and adjust capacity assumptions.

You should also discuss how the system handles partial failures gracefully. If one elevator fails, the system degrades: wait times increase, but service continues. Requests assigned to the failed elevator are re-queued and reassigned. If the state store becomes temporarily inconsistent, the controller should prefer conservative decisions rather than issuing conflicting commands.

Common pitfall: Ignoring failure modes because “it’s just an interview.” In real systems, failure handling is the difference between a schedule and a service.

Summary (after the explanation):

• Car controller enforces safety; scheduler optimizes service.

• Detect failures via heartbeats and sensor signals.

• Reassign requests when an elevator goes offline.

Scaling from centralized to hierarchical/zoned control#

A centralized controller works well for small to medium buildings. It maintains global state and makes globally optimal decisions. But as buildings get taller and elevator counts increase, a single controller can become a bottleneck and global optimization becomes less useful. Traffic patterns become localized: lower floors behave differently from upper floors.

The standard evolution is zoning and hierarchical control. You partition the building into zones (low-rise, mid-rise, high-rise) and assign elevator groups to zones. Each zone has a local controller that handles most decisions, and a higher-level coordinator handles cross-zone traffic and mode switching (rush hour strategies, service elevator routing).

This evolution also reduces state complexity. Instead of every elevator competing for every request, only a subset is eligible. That improves performance and predictability. In interviews, this is an excellent “level-up” move: start with centralized control, then describe how you scale it.

Interview signal: “Centralized first, then zone-based/hierarchical for tall buildings” is the right progression. It shows you can design an MVP and an evolution path.

Summary (after the explanation):

• Centralized control is simplest and works for smaller systems.

• Zoning reduces complexity and improves scalability in tall buildings.

• Hierarchical control enables mode-based tuning and coordination.

Observability and tuning in production#

A real elevator scheduling system is not “set and forget.” You deploy a baseline policy, measure outcomes, and tune weights and modes over time. Interviewers love when candidates talk about metrics because it shows you understand real-world iteration.

Start with rider-centric metrics: wait time percentiles, travel time, and stop counts. Then add system-centric metrics: utilization per elevator, direction reversals, reassignment rate, and starvation indicators (max wait). These metrics tell you whether your policies are working or if they need tuning.

The tuning loop is straightforward: detect traffic mode (up-peak, down-peak, mixed), adjust scoring weights and batching thresholds, and validate improvements using A/B testing or shadow evaluation. For example, you can simulate assignment decisions with recorded request traces and compare outcomes before changing production behavior.

What to say in the interview: “I’ll start with a simple policy, measure p95 wait and max wait, then tune assignment weights and batching thresholds based on observed traffic patterns.”

Summary (after the explanation):

• Track wait time percentiles and max wait for fairness.

• Monitor reversals and reassignment for stability.

• Tune weights and batching based on traffic mode detection.

How to structure your interview answer#

Acing this interview is mostly about structure. You want to guide the conversation: clarify goals, define request types, propose architecture, explain scheduling, then handle edge cases and scaling. This order keeps you in control and prevents getting trapped in algorithm trivia too early.

When the interviewer challenges your approach, respond by extending your model rather than replacing it. If they ask about fairness, add aging. If they ask about rush hour, add mode switching. If they ask about tall buildings, add zoning. That’s exactly how real systems evolve.

Interview signal: The best answers are composable. You start simple, then add fairness, batching, zoning, and observability as requirements expand.

Summary (after the explanation):

• Start with goals and clarifying questions.

• Separate hall calls from cab calls.

• Use a scoring model for assignment and a directional policy for routing.

• Add fairness, peak modes, zoning, and metrics as follow-ups.

Common mistakes to avoid#

A lot of elevator answers fail for predictable reasons. The biggest one is treating scheduling as the only problem and skipping the request model and system state. Another is assuming you can optimize purely for average wait time, which often produces starvation. A third is designing an overcomplicated algorithm without a clear explanation of what it improves.

A strong answer stays grounded: simple baseline, measurable goals, and incremental sophistication. That’s what interviewers trust.

Common pitfall: Over-engineering early. A simple LOOK/SCAN baseline plus a clear assignment score is better than an opaque “AI scheduler” with no guarantees.

Summary (after the explanation):

• Don’t skip hall vs cab call modeling.

• Don’t optimize only for average wait; protect fairness.

• Don’t overcomplicate before you define goals and metrics.

Final takeaway#

Elevator System Design interviews reward structured thinking more than clever algorithms. The winning approach is to define the request model, build a controller with clear responsibilities, choose a baseline scheduling policy, and assign hall calls using a tunable scoring model that balances ETA, direction, and fairness. Then you show maturity by covering failure handling, scaling via zoning, and production observability.

If you present the design in that order—and explain trade-offs confidently—you’ll deliver the kind of answer interviewers associate with senior and Staff-level engineers.

Happy learning!