Airbnb: Migrating to Service-Oriented Architecture
How Airbnb broke apart a decade-old Ruby on Rails monolith into hundreds of independent services without ever taking the site offline.
The challenge
By 2017, Airbnb's original Rails monolith had grown to millions of lines of code maintained by hundreds of engineers. Every deployment required coordinating across dozens of teams, a single bug could take down the entire platform, and the codebase had become so tightly coupled that even small changes required understanding vast portions of unrelated functionality. Engineering velocity was visibly slowing as the company scaled.
The strategy
Airbnb committed to a service-oriented architecture migration — breaking the monolith into independently deployable services owned by individual teams. Critically, the strategy required this migration to happen incrementally, with the live site running continuously throughout, rather than a risky big-bang rewrite that could halt the business for months.
Want the full story, outcome and quiz?
Read how Airbnb executed it, the results, key lessons and test yourself with a quiz. Free on CaseLearn.
Try the full case free →Key lessons (preview)
- Large-scale architecture migrations should happen incrementally, not as risky big-bang rewrites.
- The strangler fig pattern — running old and new systems in parallel during transition — reduces migration risk significantly.
- Monolith-to-services migrations are as much an organisational challenge (team ownership boundaries) as a technical one.