Airbnb's Service-Oriented Migration

The starting position

A large Rails monolith, growing team, slowing builds and deploys, and the familiar coupling where any change risks anything. The standard decomposition story — and the interesting part is the sequence they chose.

The order of operations

Data access first, not services first. The usual failure in monolith decomposition is extracting a service that still reaches into the monolith's database, which distributes the code without distributing the data — leaving every consumer coupled to a schema and every "service boundary" fictional.

Airbnb's published work describes building a unified data-access layer that made data ownership explicit and gave services a defined way to read and write, before and during service extraction. Getting the data boundary right is most of the work; the service boundary follows from it.

Explicit service tiers with dependency rules. Rather than an arbitrary graph, services were categorised — data services owning a domain's data, derived-data services, middle-tier services composing them, presentation services — with rules about which tier may call which. The same insight as Uber's DOMA: an unconstrained service graph becomes unreadable, and layering restores direction.

Centralised authorisation. Airbnb built a dedicated authorisation service ("Himeji") so that permission decisions were made in one auditable place rather than reimplemented in every service. A recurring finding in decomposition: cross-cutting concerns that were implicit in a monolith must become explicit services or they fragment.

The lessons

1. Decompose data before decomposing code. A service that does not own its data is not a service.

2. Constrain the service graph from the start. Layers or domains, with enforced dependency direction. Retrofitting structure onto a large arbitrary graph is far harder than establishing it early.

3. Identify the cross-cutting concerns early — authorisation, identity propagation, feature flags, configuration, observability. In a monolith they are function calls; in a service estate each must become a deliberate piece of platform, and discovering that late means each team has already built its own.

4. Migration is measured in years. Published accounts of this kind of decomposition consistently describe multi-year programmes running alongside product delivery. Plans assuming otherwise are the reason so many stall halfway and leave both architectures in place.