Airbnb: Monorail to Service-Oriented Architecture
also called Airbnb SOA Migration
Airbnb decomposed a large Rails monolith into services, and the difficult part was data ownership rather than code extraction.
The problem
Airbnb's monolith — internally "Monorail" — had grown to the point where it constrained the organisation rather than the technology. Build and test times were long, a change anywhere risked anything, deployment required coordination across many teams, and ownership of any given piece of behaviour was ambiguous.
The trigger for decomposition is almost always this organisational one. The monolith was not slow; the teams were.
What they did
They moved to a service-oriented architecture over several years, and the published accounts emphasise a point that is easy to miss: the hard problem was data, not code.
Extracting a service's logic is comparatively mechanical. Extracting its data means deciding which service owns each table, removing the joins that other parts of the system relied on, and replacing direct database reads with API calls — which changes latency, failure modes and consistency for every consumer.
They also invested in the supporting layers that make an SOA tractable: a unified data access layer, service discovery, standardised service scaffolding, and later a dedicated authorisation service so that permission logic was not reimplemented per service.
The trade-off
Decomposition bought independent deployment, clear ownership and scoped blast radius. It cost network calls where there had been function calls, eventual consistency where there had been transactions, distributed debugging, and a substantial platform investment that had to be funded before the benefits arrived.
Airbnb was explicit that the migration took years and required building platform capability alongside — not as an afterthought.
The transferable lesson
Sequence by data ownership. The question that determines whether a service boundary is real is not "can we extract this code" but "can this service own its data exclusively, with no other service reading its tables". If the answer is no, you are building a distributed monolith.
And the corollary for anyone planning a decomposition: budget the platform work explicitly. Service discovery, deployment, observability, contract testing and authorisation must exist before the tenth service, or the estate becomes ungovernable at exactly the point it is too late to reverse.