Integration & APIs 23 Sep 2026 29 min read

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 finding that surprised me

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.

Open the field guide → Self-contained: it loads nothing at read time, follows your system theme, and prints cleanly.