Design Elevator System
Last Updated: February 7, 2026
What is an Elevator System?
An elevator system is a combination of mechanical components and software logic used in multi-story buildings to transport people or goods vertically between floors.
Loading simulation...
Modern elevator systems typically consist of one or more elevator cars (also called lifts), each controlled by an embedded software system that manages a range of operations, including:
- Movement control (moving the elevator up or down)
- Door operations (opening and closing doors safely and efficiently)
- User request handling (both from inside and outside the elevator)
- Scheduling logic to decide which elevator responds to which request, in what order, and in which direction
In this chapter, we will explore the low-level design of an elevator system in detail.
Lets start by clarifying the requirements:
1. Clarifying Requirements
Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions and better define the scope of the system.
Here is an example of how a conversation between the candidate and the interviewer might unfold:
Candidate: "How many floors and elevators should the system support?"
Interviewer: "Let's design for a 10-floor building with 3 elevators. But the design should be flexible enough to scale to more."
Candidate: "Should the system handle both internal requests (floor buttons inside the elevator) and external requests (hall calls from each floor)?"
Interviewer: "Yes, the system should support both internal and external requests. Internal requests specify only a destination floor. External requests specify a floor and a desired direction (up or down)."
Candidate: "Should we follow a specific elevator scheduling algorithm, like SCAN or LOOK, or is a basic first-come-first-serve strategy sufficient?"
Interviewer: "You can start with a simple scheduling strategy like nearest elevator first. However, the design should be extensible enough to support pluggable scheduling algorithms in the future."
Candidate: "Should each floor and elevator cabin have a display showing the current floor and direction?"
Interviewer: "Yes. Displays should update whenever an elevator's state changes, but the elevator itself shouldn't know about displays directly."
Candidate: "Should each elevator run independently in its own thread?"
Interviewer: "Yes. Each elevator should have its own controller running in a separate thread."
Candidate: "Do we need to handle user input, or can we hardcode test scenarios?"
Interviewer: "Hardcode the scenarios. Focus on the design, not the I/O."
After gathering the details, we can summarize the key system requirements.
1.1 Functional Requirements
- Support multiple elevators serving multiple floors in a building
- Handle internal requests (cabin buttons) and external requests (hall buttons with direction)
- Dispatch external requests to the most suitable elevator using a configurable strategy
- Each elevator uses the LOOK algorithm to serve requests efficiently
- Display current floor and direction on each floor and inside each elevator cabin
- Each elevator operates independently in its own thread
1.2 Non-Functional Requirements
- The design should follow object-oriented principles with clear separation of concerns
- The system should be modular and extensible to support new dispatch strategies
- The code should be thread-safe for concurrent elevator operations
- The components should be testable in isolation
- The dispatch strategy should be swappable at runtime without modifying existing code
Elevator Movement Algorithms
The most naive approach is FIFO (First-In, First-Out): serve requests in the order they arrive. If the elevator is on floor 1 and receives requests for floors 8, 3, and 6 in that order, it goes 1 → 8 → 3 → 6. That's a lot of unnecessary back-and-forth. Passengers on floors the elevator passes right by have to wait while it chases requests in arrival order.
A better idea is SCAN (sometimes called the "elevator algorithm", ironically). The elevator moves in one direction, serving all requests along the way, then reverses and does the same in the opposite direction. It always travels to the very end of its range before reversing, even if there are no more requests in that direction.
LOOK improves on SCAN with one key tweak: instead of traveling all the way to the top or bottom floor, the elevator only goes as far as the highest (or lowest) pending request in its current direction, then reverses immediately. It "looks ahead" to see if there are more requests before continuing, hence the name.
Here's a concrete example. Imagine a 10-floor building where an elevator is on floor 3, moving UP, with pending requests for floors 5, 7, and 2:
LOOK and FIFO happen to visit the same floors in this example, but the difference shows up under load. With FIFO, if a new request for floor 4 arrives while the elevator is heading to floor 7, it won't be served until after the trip down to floor 2 and back. With LOOK, the elevator serves 4 on the way down because it processes all requests in its current direction of travel.
The LOOK algorithm gives us the best trade-off for elevators: it minimizes unnecessary travel (unlike FIFO), avoids wasted trips to empty extremes (unlike SCAN), and it's simple enough to implement with just two sorted sets, one for each direction. We'll see exactly how those sets work when we build the Elevator class.
Now that we understand what we're building and the algorithm driving it, let's identify the building blocks of our system.