The Architecture of Elevator Algorithms (Yes, They Run on Code)

By

Published on

in

There is a ritual that takes place in office lobbies and high-rise apartments every morning: you press the call button, step back, and stare at a small digital number that refuses to move.

After thirty seconds of silence, you begin the quiet psychological negotiation. You wonder why the lift is currently going up to floor 14 when four people are standing on the ground floor. You wonder if pressing the button a second time will assert your dominance over the machinery. And when the doors finally slide open, empty, traveling in the exact opposite direction of where you need to go, you realize you have just been judged and found wanting by a mathematical formula.

We tend to treat elevators like heavy mechanical counterweights attached to thick steel cables. But the moment you have more than one floor and more than one passenger, a lift stops being a box on a string.

It becomes an active, real-time scheduling problem running on code.

The Naive Approach (Or, How to Make Everyone Late)

If you sat down to write elevator software from scratch with no prior experience, your first instinct would probably be the simplest queue possible: First-Come, First-Served (FCFS).

Someone on floor 2 presses the button, so the elevator goes to floor 2. While moving, someone on floor 9 calls it, followed immediately by someone on floor 3. The elevator finishes at floor 2, journeys all the way up to 9, and then drives all the way back down to 3.

It is fair in the most literal, bureaucratic sense. It is also an absolute logistical nightmare.

Under an FCFS queue, the elevator wastes most of its operating life traveling empty over floors it could have easily serviced on the way past. Energy consumption spikes, wait times compound exponentially, and anyone trying to leave during a morning rush would simply give up and take the stairs.

To fix this, engineers in the mid-20th century realized an elevator shouldn’t just serve requests in the order they arrive; it needs a sweeping strategy.

The SCAN Algorithm

The standard logic powering most modern elevators is remarkably elegant, and it has a direct name in computer science: the SCAN algorithm (often literally nicknamed the Elevator Algorithm).

The rules are simple:

  1. Pick a direction (say, UP) and keep moving in that direction as long as there are pending requests above you, either from people inside wanting to get off, or people outside wanting to go up.
  2. Stop at every requested floor along that path to let people in and out.
  3. Only when there are no more requests higher up do you change direction to DOWN and repeat the process in reverse.

It feels completely intuitive. By maintaining direction until the path is exhausted, the elevator eliminates the back and forth of the naive approach.

The fun part? Computer scientists loved this logic so much that they took it out of physical buildings and copied it directly into computer hardware.

For decades, traditional mechanical hard drives used the exact same SCAN algorithm to control the physical read/write head sweeping across magnetic spinning platters. When your operating system needed to fetch three files from different tracks on the disk, it moved the arm across the surface in one continuous direction rather than jerking it randomly back and forth.

The software shuttling you to your morning meeting is the identical logic that retrieved your saved documents in 1998.

Group Dispatching and Destination Control

While the standard SCAN algorithm works well for a single lift in a three-story building, it begins to fracture when you step into a 40-story office tower with a bank of eight elevators.

If all eight cars blindly follow their own basic SCAN loops, you get the classic bunching phenomenon: three elevators arrive at the lobby at the exact same moment, all half-full, while the top floors starve for a ride.

To solve this, modern skyscraper architecture uses Destination Dispatch Systems.

You’ve probably encountered these in newer corporate buildings: there are no buttons inside the lift car itself. Instead, you enter your target floor on a touchscreen in the lobby before you board.

The central controller takes your destination, pairs it with the destinations of the fifteen people standing around you, and solves a real-time knapsack optimization problem.

By forcing humans to declare their intent before stepping into the box, the software eliminates intermediate stops, halves the total transit time, and strips away the awkward social panic of standing near the door hoping nobody presses floor 3.

The Math of Everyday Life

We spend our days surrounded by invisible algorithms that we only notice when they fail.

We notice the traffic light that stays red when the road is empty. We notice the buffering icon on a video player. And we notice the lift that seems to hover three floors above us while we tap our feet on the tile.

Behind that frosted steel door, a small microcontroller is quietly balancing kinetic energy, waiting passenger queues, direction momentum, and time-decay curves just to deliver you to your desk with minimal drama.

The next time you’re standing in the lobby waiting for the arrow to light up, don’t take it personally. The code is just finishing its sweep.


Enjoyed the breakdown?

If you love peeling back the everyday technology around us to see the algorithms, design choices, and quiet code running under the surface, you’re in the right place.

Subscribe below to get fresh essays on software architecture, tech history, and systems thinking delivered straight to your inbox.

Leave a Reply

Discover more from Days in the Life of Mo

Subscribe now to keep reading and get access to the full archive.

Continue reading