Airbnb
Airbnb: growing up on AWS
A Rails monolith on 200 EC2 instances became 250 services, and every step of the surgery happened while the marketplace stayed open.
The early stack: ELB, EC2, and a Multi-AZ RDS migration
Airbnb launched in 2008 and moved onto AWS early. The official AWS case study describes the first-generation stack plainly: about 200 EC2 instances running the application, memcache, and search, with Elastic Load Balancing spreading incoming traffic across them. Amazon S3 held backups, static files, and roughly 10 terabytes of user pictures. Amazon EMR crunched about 50 gigabytes of data daily, and CloudWatch watched the fleet.
The database story is the part worth remembering. Airbnb moved its main MySQL database to Amazon RDS and, per the case study, completed that migration with only 15 minutes of downtime, then ran it as a Multi-AZ deployment so a failure in one Availability Zone would not take bookings offline. For a two-sided marketplace this is the core constraint: when the site is down, guests cannot book and hosts cannot earn, so every minute of unavailability costs both sides of the market at once. Offloading replication, failover, and backups to a managed Multi-AZ database bought that availability without hiring a database operations team; Airbnb's CTO Nathan Blecharczyk framed AWS as 'the easy answer for any Internet business that wants to scale.'
The application itself was a single Ruby on Rails codebase the company called Monorail. That worked for years. But by 2015, per Airbnb infrastructure engineer Jessica Tai's QCon SF 2018 talk, more than 200 engineers were pushing around 200 commits a day into it, and reverts and rollbacks were blocking deploys for roughly 15 hours a week. The monolith had become both a delivery bottleneck and a single point of failure, which set up the second act.
First-generation stack: ELB, a stateless EC2 fleet, and Multi-AZ RDSFollowing a request through the two generations
Trace a request for a listing page down both paths in the diagram. In the monolith era the path is short: the guest's request hits Elastic Load Balancing, lands on one of the interchangeable EC2 instances running Monorail, and Monorail does everything itself, rendering the page, running business logic, and querying the Multi-AZ RDS MySQL database directly, with images served from S3. Short paths are simple, but every feature shares one deploy, one process, and one blast radius.
In the service-oriented generation the same request takes more hops, each with a defined job. Requests enter through an API gateway layer that routes to the relevant service. A presentation service synthesizes the response the client needs. It calls derived data services, which apply business logic over shared data. Those in turn call data services, which are the only components allowed to read or write their slice of the database; nothing else touches the tables. Airbnb added a fourth tier later, middle-tier utility services, for validation logic that multiple services needed. Strict layering was the rule: calls flow downward, so a failure or a bad deploy in one service has a bounded blast radius instead of taking the whole application with it.
The migration itself is the most exam-relevant part of the story. Airbnb did not cut over; it moved traffic per endpoint and per attribute behind configurable feature gates, starting at 1 percent and ramping to 100. A dual-read comparison framework replayed reads against both Monorail and the new service and diffed the responses; writes went to shadow databases whose results were verified against production before the new path took real traffic. A custom ActiveRecord adapter intercepted SQL queries inside the monolith and routed them to services without rewriting thousands of call sites. The service framework standardized the rest: services expose Thrift IDL contracts, and the generated RPC clients ship with timeouts, retries, and circuit breakers by default, so resilience is a property of the platform rather than a per-team afterthought. The results Tai reported: over 250 services, deploys that went from hours to minutes, some pages up to 10x faster, and 1,000 engineers shipping about 10,000 deploys a week. Services initially ran on EC2, with the company later moving toward Kubernetes for scheduling.
Two request paths and the migration machinery between themWhat this teaches for the exam
For task 2.1, designing scalable and loosely coupled architectures, Airbnb's trajectory is the canonical shape. Stateless application instances behind a load balancer scale horizontally because the load balancer, not the client, decides where a request lands; that is why ELB in front of an EC2 fleet (today an Auto Scaling group behind an ALB) is the default answer for web tiers. Loose coupling came from drawing service boundaries around data ownership and forcing all access through a contract: Airbnb used Thrift IDL and an in-house gateway, and the exam expresses the same idea with Amazon API Gateway fronting REST APIs. When a question mentions retries, timeouts, or circuit breakers, remember that Airbnb baked those into every generated client; on the exam the analogous move is buffering with SQS, decoupling with SNS or EventBridge, and never letting one slow dependency stall a synchronous chain. Also notice what Airbnb did not build: RDS, S3, EMR, and CloudWatch are all managed services chosen so a small team could spend its hours on the marketplace instead of on infrastructure plumbing.
For task 2.2, high availability and fault tolerance, the study gives you three reusable patterns. First, Multi-AZ RDS: synchronous standby in another Availability Zone, automatic failover, no application rearchitecture required. Exam questions that pair 'relational database' with 'survive an AZ failure' are pointing here, and questions about read scaling point to read replicas instead; know the difference. Second, health-checked fleets behind a load balancer mean any single instance can die without a user noticing, which is fault tolerance at the compute tier. Third, and most transferable, is how Airbnb shifted traffic: 1 percent at a time behind feature gates with automated response comparison. That is exactly the reasoning behind weighted Route 53 records, ALB weighted target groups, and canary deployments in exam scenarios; the safe answer moves a small, measurable slice of traffic and verifies before ramping. Finally, the monolith itself is the lesson in single points of failure: one codebase where any bad deploy can take down everything is the anti-pattern the entire domain 2 exists to design away.
The exam-canonical translation of Airbnb's patternsMore diagrams
Sources
Practice what you just read