Fun argues that elevator dispatch — a stochastic, capacity-constrained, hard-real-time multi-agent scheduling problem — has been rigorously solved by the elevator industry for decades via destination control and group supervisory algorithms. He walks through the Mitsubishi and Otis patent lineage to show that predictive assignment, multi-objective cost functions, and mid-execution rebalancing were formalized in the 1970s, long before modern distributed systems engineers reinvented weaker version
The editorial highlights that what makes elevator scheduling categorically different from typical software scheduling is the absence of a failure mode: the system must always produce a physically executable assignment. This forces designs that prioritize guaranteed liveness and graceful degradation over the retry-and-backoff patterns that dominate modern service architectures.
The 1,060-point score and 254-comment thread reflect a collective realization among developers that job queues, load balancers, and task schedulers in their own systems are rediscovering — often poorly — patterns already codified in fifty-year-old elevator patents. Domain practitioners in the thread reinforced this by confirming what the post got right, while other engineers pattern-matched the ideas onto their own architectures with visible embarrassment.
A blog post titled simply *Elevators* by John Fun landed on Hacker News this week and pulled 1,060 points, which for a piece about vertical transportation is a genuinely strange outcome. The post walks through how modern elevator dispatch actually works — destination control systems, zone assignment, the Mitsubishi and Otis patent lineage — and ends up somewhere developers didn't expect: staring at a scheduling problem that our industry keeps solving badly, decades after the elevator industry solved it well.
The author's core observation is that a bank of elevators in a 40-story building is a constrained multi-agent scheduler with hard real-time properties. Passenger requests arrive stochastically. Cars have finite capacity. Travel time is non-uniform. Preemption is impossible once a car is committed. And — the part that keeps getting glossed over — the system cannot return an error. There is no 503 Service Unavailable for a person standing in a lobby. The scheduler must produce an answer, and that answer must be physically executable, every time.
Mitsubishi's destination control patents from the 1970s and Otis's later work on group supervisory control describe algorithms that look, in retrospect, a lot like what a modern distributed systems engineer would sketch on a whiteboard: predictive assignment based on expected passenger flow, cost functions that weight waiting time against travel time against energy use, and — critically — a supervisory layer that can rebalance mid-execution without dropping in-flight commitments. The math has been sitting in patent filings and IEEE journals for fifty years.
The HN comment thread is doing what HN comment threads do when a small tool or essay goes viral: half the top comments are people who actually work in the domain patiently explaining what the post got right, and half are developers pattern-matching the ideas onto their own stack and discovering — with some embarrassment — that their production systems handle backpressure worse than a 1974 Otis controller. Both halves are useful. The domain experts anchor the discussion; the pattern-matchers do the translation work that makes the essay actually valuable outside its niche.
What the comments reveal, and what the essay itself only hints at, is that the elevator industry made a set of engineering commitments that our industry has quietly walked away from. Elevators cannot drop requests. They cannot say 'try again in a minute.' They cannot silently degrade to a slower path and hope nobody notices. When capacity is exhausted, the failure mode is explicit and legible: a car arrives, it's full, you wait for the next one, and the wait time is bounded by a contract the building owner signed. There is no equivalent contract for your job queue. There is no equivalent contract for your API gateway. There is barely an equivalent contract for your database.
The comparisons write themselves. Kubernetes' scheduler makes placement decisions that superficially resemble destination control — bin-packing pods onto nodes based on resource requests and affinity rules — but its failure mode when the cluster is saturated is to leave pods Pending indefinitely, which is the software equivalent of an elevator that shows up, opens its doors, and refuses to move. Load balancers advertise 'graceful degradation' and mean 'we'll shed load and hope the retry storm doesn't kill us.' Message queues advertise 'at-least-once delivery' and mean 'we've moved the deduplication problem to you.' Elevator controllers don't get to move problems to the passenger.
And yet — and this is where the essay gets its real bite — the elevator industry didn't achieve this by being smarter than us. They achieved it by having no other option. The physical reality of the domain forced a discipline that our domain, where the cost of dropping a request is usually just an angry Slack message, never had to develop. When you can return 503, you will. When you can't, you build a different kind of system.
The single-source signal here deserves the usual skepticism. One viral essay on HN is not a paradigm shift. The elevator industry has its own failure modes — the destination control systems everyone in the thread is praising are notorious for confusing first-time users, and the algorithms are tuned for statistical throughput in ways that can produce genuinely bad individual experiences. It is not the case that Mitsubishi's engineers have nothing to learn from us. But the discipline of designing a scheduler that cannot fail is a discipline our industry has largely opted out of, and reading a good essay about a domain that couldn't opt out is a useful corrective.
The actionable read here isn't 'go implement destination control in your job queue.' The actionable read is that most of the scheduling code you've written or inherited has an implicit escape hatch — retry, defer, drop, alert a human — and that escape hatch is doing more load-bearing work than your architecture diagram admits. Audit it. Find the places where your system's response to saturation is 'return an error and hope,' and ask whether the caller actually has a plan for that error, or whether you're just moving the failure one layer up the stack until it reaches a human who also doesn't have a plan.
The second read is about admission control. Elevator systems don't let you press a button that the system can't honor; the button goes dark, or the destination panel refuses the input, or the car simply doesn't stop. Most web systems accept every request at the edge and only discover they can't fulfill it several layers deep, after they've already spent resources on it. Rejecting a request at the door is cheaper than rejecting it at the database, and it produces a better failure mode for the caller. This is not a new idea — Little's Law and the entire queueing-theory literature have been shouting it for decades — but it's an idea that gets rediscovered every time somebody reads a good essay about a domain that took it seriously.
The third read is about SLAs as engineering inputs rather than marketing outputs. Building codes specify elevator wait times. Insurance policies specify elevator reliability. Those numbers flow backward into the algorithm design. Most software SLAs are written after the system is built, by a product manager reverse-engineering what the system happens to deliver on a good day. If your uptime target is a description rather than a constraint, your scheduler is not being held to elevator standards, and it will not behave like one.
The essay will fade from HN's front page by tomorrow and the pattern will repeat: another domain with fifty years of hard-won engineering discipline will go viral, developers will nod, and the next production incident will still be a scheduler that responded to saturation by making things worse. The value of pieces like this isn't that they'll change how you build things this week. It's that they widen the reference set. The next time you're designing a system where failure has to be legible and bounded, you'll have a mental model that isn't just 'exponential backoff and pray' — you'll have a Mitsubishi controller from 1974 in the back of your head, quietly refusing to return 503.
The worst situation I've encountered is after a large conference when everyone is leaving the hotel at once. An elevator quickly fills up on the way down, but then wastes time stopping at every subsequent floor with a call, even though no one else can fit inside. At each floor the elevator stop
> Destination Dispatch [...] are in general worseI wonder if this is an artifact of how the author used random destinations. I worked in a building that used Destination Dispatch, and the common travel pattern seemed to be:- Everyone who is not on the ground floor generally want to go to the grou
For folks that have never seen elevator scheduling the game: https://play.elevatorsaga.com/ Enjoy this rabbit hole :D
Hah, I thought a lot about this problem while developing Sky Lobby, a mobile game (iOS / Android) about controlling and automating elevators.In the game, some of the elevators are automated, and I wanted to choose an algorithm that best aligned with what players would expect an elevator to do.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Back in highschool, simulating different elevator algorithms was one of the projects I implemented during my CS class. It wasn't for the class — AP CS did not require anything like actual programming — but it was a fun project.A cool connection is that a spinning-disk hard drive (HDD) is actual