Yesterday, an interactive article explaining how elevators navigate reached the top spot on Hacker News—earning 771 points and 198 comments. Developers spent the entire day debating how elevators work.
The conversation kicked off with a counterintuitive observation: many modern office buildings have moved floor selection buttons out of the elevator cabs and into the lobby. You select your destination floor before stepping in, and the system assigns you a specific car. Yet in most simulated scenarios, this “Destination Dispatch” system turns out to be slower than traditional Up/Down buttons. The comment section quickly filled with elevator engineers, disk driver developers, and hotel facility managers sharing their perspectives.
Elevators are something almost everyone uses every day, yet few understand the underlying complexity. The article uses interactive simulations to break down the mechanics: each algorithm comes with a speed-adjustable animation where readers can add floors and cars to watch wait-time distributions shift in real time. HN commenters added valuable real-world nuances, which we’ve synthesized below.
Why Elevator Scheduling Is Hard
Start with the physical constraints. A single elevator can only move in one direction at a time; passenger capacity is limited; and higher floor counts multiply the choices. When multiple cars operate concurrently, deciding who gets picked up and in what order becomes a complex scheduling problem.
Passenger traffic flow is also heavily asymmetrical. In an office building during morning rush hour, nearly everyone travels from the lobby to upper floors. During evening rush hour, it’s the exact reverse. At lunchtime, traffic becomes a chaotic mix. A single static rule set produces vastly different performance across these periods—morning rush hour wait-time metrics are notoriously difficult to optimize.
Another layer of complexity stems from group dispatching. Office elevators usually operate as a bank sharing a unified call button panel, with five or six cars servicing the same pool of calls. When you press “Up”, the system must decide which car to assign. This decision is continuously re-evaluated as cars move, passengers board, and requests change. That’s the core difficulty: single-elevator rules are simple, but multi-car coordination is notoriously complex.
How Traditional Elevators Work
The most common baseline algorithm is SCAN, patented as early as 1961. The elevator travels from the lobby all the way to the top floor, then reverses direction to head down, stopping for anyone along the way—much like a bus picking up passengers along its route. It is commonly referred to as the “Elevator Algorithm” because computer scientists realized disk heads sweep across physical hard drives in the exact same pattern and borrowed the term.
Since passengers rarely all need to go to the top floor, a refined variant called LOOK was developed. Under LOOK, the car travels only as far as the highest requested floor in its current direction before reversing. This aligns with standard elevator behavior: maintain direction, pick up passengers on the way, and reverse only when no further calls remain ahead.
Figure: Interactive elevator simulation from John.fun. Source: john.fun/elevators
The benchmark for elevator quality is wait time, specifically analyzed through percentiles: p50 measures median wait time, while p90 measures the duration 90% of passengers experience. Few people remember average wait times; what sticks in memory are those rare moments when you waited “what felt like an eternity.” Consequently, algorithm optimization primarily focuses on capping p90 tail latency.
Figure: Wait time distribution demo from John.fun. Source: john.fun/elevators
There is also a fundamental trade-off: short wait times do not guarantee short trips. To pick up more passengers along the route, an elevator makes frequent stops, increasing in-cabin travel time. Minimizing wait time often comes at the expense of trip duration, and scheduling algorithms must strike a delicate balance between the two.
Smarter Isn’t Always Better
In multi-car systems, a naive approach is central dispatch: assign new requests to the nearest available car. Engineers sought better solutions. Otis developed the RSR (Relative System Response) algorithm, which assigns dynamic scores to cars based on estimated time of arrival, current passenger load, anti-clustering penalties, direction alignment, and nearby idle cars. The car with the best score takes the assignment. The system re-evaluates every 5 seconds; if Car A gets delayed, the task can be reassigned to Car B.
RSR includes an anti-clustering rule: if another car is already en route to a floor, others avoid responding to the same call. When two elevators arrive simultaneously in an office lobby to greet you, it indicates a failure in anti-clustering. Scoring happens dynamically in real time, shifting with every floor a car moves.
However, simulation results reveal a surprising catch: under high traffic loads, simple LOOK frequently outperforms complex RSR. In smaller buildings with fewer elevators, LOOK consistently wins out as well. More rules do not necessarily yield higher throughput; sometimes simplicity wins. It serves as a reminder for engineering: between algorithm complexity and performance gain lies the reality of specific operational workloads.
The Debate Around Destination Dispatch
The core logic of Destination Dispatch is intuitive: since the system knows everyone’s destination floor in advance, it can group passengers heading to the same floor into the same car, drastically reducing intermediate stops. With complete information, theoretical efficiency should be higher. These kiosk-style systems are now common in hotels, hospitals, and high-rise office towers.
Yet the article’s simulation demonstrated the opposite: in most scenarios, Destination Dispatch proved slower than traditional Up/Down buttons. The culprit is flexibility. Traditional elevators can re-optimize paths every 5 seconds. Destination Dispatch, by contrast, locks passengers into a specific assigned car the moment they interact with the kiosk. 30 seconds later, floor demand patterns may change completely, but the system cannot reassign passengers. The gain from extra information fails to offset the loss in real-time adaptivity.
HN commenters pushed back against this conclusion. Engineers pointed out that real-world office lunch hours involve large crowds traveling to the exact same cafeteria floor simultaneously—a pattern where Destination Dispatch excels through batching. Similarly, hotel morning peak traffic switches to dedicated breakfast modes. Because the simulation did not model these specialized traffic modes, its conclusions naturally favored older algorithms. Both points hold merit: the efficacy of Destination Dispatch depends heavily on specific traffic patterns. While it remains popular in modern landmarks, the notion that “newer is always faster” does not universally hold.
Figure: Destination Dispatch demo from John.fun. Source: john.fun/elevators
A Hard Drive Is a Rolled-Up Elevator
One striking insight highlighted in the comments is that the SCAN algorithm is identical to the disk head scheduling algorithm used in computer hard drives. On Wikipedia, the entry is listed under both “Elevator algorithm” and “SCAN”. It originated as a method to schedule disk read/write requests.
Inside a mechanical hard drive, the read/write head seeks across platter tracks just as an elevator moves across floors to pick up passengers. Read/write requests are scattered across disk tracks; the head sweeps in one direction, fulfilling requests along the path, and reverses upon reaching the end. Disk head seeking is among the slowest mechanical operations in a computer, and scheduling saves precious mechanical seek latency. As one developer quipped: “A hard drive is just a rolled-up elevator.”
In computer science textbooks, SCAN remains a classic chapter in I/O disk scheduling. The 1961 elevator patent and operating system textbooks rely on identical principles. When Donald Knuth discussed coroutines in The Art of Computer Programming, his primary example was simulating an elevator. One transports people, the other transports data, but the underlying scheduling logic is identical.
While SCAN is gradually retiring from modern hard drives—where Solid State Drives (SSDs) reduce seek times to near zero—it continues to run daily inside elevator shafts around the world. The exact same concept has spanned mechanical engineering and computer science for over six decades.
Conclusion
When an elevator takes time to arrive, it’s not ignoring you—it simply has a lot of variables to balance. Next time you find yourself waiting for an elevator, consider this: behind every button press, generations of engineers have debated how to make the math faster, and some of those debates remain open to this day.
Reference Links:
- John.fun: Elevators Interactive Explainer
- HN Discussion (item?id=49124218)
