Putting the services back together: ten years of Airbnb, read from its own artefacts
How Airbnb's architecture changed between 2015 and 2026, reconstructed from its repositories, implementation documents and package registries: what it split into services, what it stopped publishing, what it now forks instead of building, and the layer it built to re-aggregate hundreds of services without merging any of them.
Reconstructs a decade of one company's architecture from artefacts rather than announcements: release timestamps on five package registries, archive notices, in-repository design documents and two security advisories. A reader leaves able to argue the hosted-logic case against the thin-gateway orthodoxy with Airbnb's own operating numbers attached, to price a process boundary using the bill the Airbnb platform team itself wrote down, and to date any vendor's architectural decisions from its registries when its engineering blog says nothing.
The remedy decayed the same way the disease did: four years after Viaduct was started to fix microservice sprawl, Airbnb rebuilt it from the ground up because it had acquired 'multiple ways to implement functionality and weak abstraction boundaries', which is the microservice complaint restated inside one process.
What you get out of it
- Airbnb never merged a service. It built a runtime that hosts other teams' business logic and moved logic into it, replacing the RPC boundary with a schema boundary and the service with a tenant module owned by one team.
- In the 2026 platform, running a resolver in a separate process is the experiment: core/x/remoteresolvers is marked experimental and its own design document itemises the cost, that the two processes share no engine, injector, schema, executor or registry.
- A boundary that is not mechanically checked is not a boundary. The first four years ran on team-owned directories and unenforced naming conventions, and the rebuild replaced them with build-time module config, a typed and untyped engine split, and a roadmap of enforcement mechanisms.
- The company now forks the infrastructure it runs and publishes only the programming model its own application code is written in: Istio and Slack's Astra arrive as forks, while Viaduct, Chronon and Skipper are written and released.
- Registry timestamps date the decade more honestly than archive notices do. Airbnb's published web platform stopped between December 2019 and November 2022 while its Android libraries kept shipping into 2026, and Hypernova was archived four years and nine months after its last release.
Scope
Why this, now. Airbnb published the first artefacts of Skipper, a durable-execution library that runs inside your service instead of as a workflow cluster, on 8 September 2026, eight days before this guide was researched, and it is the clearest instance yet of the pattern the decade describes.
What it does not cover. Airbnb's data platform, search and pricing systems, mobile client architecture beyond what the registries record, and all cost figures, because no artefact in this corpus carries one. The session's egress policy blocked medium.com, which hosts the Airbnb Tech Blog, as well as arxiv.org, usenix.org and sec.gov, so the guide contains no papers, no conference talks and no independently reported financial figures.
Other field guides
Making the client carry it: ten years of Discord's gateway contract
A fanout platform pays for connected consumers multiplied by events, and it cannot deploy a fix to consumers it does not own. This guide reconstructs…
28 sources · 7 organisations · 4 postmortemsThe reference architecture Netflix retired
Between 2013 and 2016 the industry copied one company's answer to service-to-service communication: discovery, load balancing, circuit breaking and c…
26 sources · 7 organisations · 4 postmortemsThe retry you are counting on was never promised
Reconstructs the sender's side of webhook delivery from GitLab's incident reviews and shipped source, GitHub's staff answers, three open-source deliv…
24 sources · 10 organisations · 4 postmortems