Guides

Airbnb Architecture Explained: How Airbnb Moved from a Rails Monolith to Services on AWS

By Ravindra Bagale, AWS & DevOps trainer · LinkedIn · Published: 18 October 2026 · Last updated: 18 October 2026

Short answer: Airbnb runs on AWS. It started as a Ruby on Rails monolith called "Monorail", then moved step by step to a service-oriented architecture (SOA), with services running on Kubernetes on AWS. Early on Airbnb moved its MySQL database to Amazon RDS and stores user photos in Amazon S3. Airbnb also created and open-sourced Apache Airflow for data pipelines and SmartStack for service discovery.

Suppose you search Airbnb for a stay in Goa

You open Airbnb, type "Goa", pick dates for a weekend and tap Search. You see a map, photos, prices and reviews, and then you book. Behind the screen, in simple terms:

1. Your app sends the search to Airbnb's servers on AWS; a load balancer receives it.
2. An API gateway routes the request to the right backend services.
3. Separate services handle search, listing details, pricing, availability and reviews.
4. Listing and booking data is read from MySQL databases (Airbnb moved MySQL to Amazon RDS).
5. Listing photos load from Amazon S3.
6. When you book, payment and reservation services do their parts, and data pipelines (scheduled by Airflow) later use this data for analytics and search ranking.

What architecture style does Airbnb use?

Airbnb's architecture story is a famous "monolith to services" migration.

1. Today (2025): Airbnb's core key-value store Mussel was rebuilt as Mussel v2, with a NewSQL backend and a stateless Dispatcher service on Kubernetes, giving p99 reads under 25 ms even for 100 TB+ tables (2025).
2. How it started, Monorail (the monolith): Airbnb's first app was one big Ruby on Rails application. As teams grew, deployments clashed and one bug could affect everyone.
3. Service-oriented architecture: Airbnb split business logic into separate services with clear owners, using standard service tooling and Thrift-based service interfaces (Building Services at Airbnb series).
4. Gradual migration: Monorail was slowly reduced to routing and views while logic moved into services.
5. Kubernetes on AWS: services moved from plain EC2 to Kubernetes clusters on AWS; Airbnb has written about dynamically scaling those clusters.
6. Service discovery: in 2013 Airbnb open-sourced SmartStack (Nerve and Synapse, using ZooKeeper and HAProxy) so services could find healthy instances of each other.

Airbnb architecture diagram (public parts)

This diagram shows only what Airbnb or its partners have shared publicly. Press Play to follow a request step by step.

What does Airbnb use? Main technologies

Which cloud provider does Airbnb use?

Airbnb uses AWS. Airbnb's early setup used

1. Amazon EC2 for application, cache and search servers.
2. Elastic Load Balancing to spread traffic.
3. Amazon EMR to process data.
4. Amazon S3 for backups, static files and user photos.
5. The main MySQL database moved to Amazon RDS, with Multi-AZ, with only about 15 minutes of downtime during the move.

Later, Airbnb moved to running services on Kubernetes clusters on AWS.

What is Apache Airflow and why did Airbnb build it?

In 2015 Airbnb open-sourced Airflow, a platform to write, schedule and monitor data pipelines as code (in Python). Airbnb uses Airflow for:

1. Data warehousing: cleaning and publishing data.
2. Growth analytics and A/B experiment results.
3. Email targeting.
4. Search ranking metrics.
5. Data infrastructure maintenance (cleanup, retention).

Today Airflow is an Apache project used by thousands of companies, and AWS even offers it as a managed service (Amazon MWAA).

How does Airbnb store data?

1. MySQL on Amazon RDS for core data.
2. Amazon S3 for photos, static files and backups; Airbnb also uses S3 for long-term storage of data retired from HDFS.
3. A data warehouse built on Hive, with Spark and Presto for processing.
4. The current exact database mix across all services is not publicly shared.

How does Airbnb monitor its systems?

1. Every Airbnb HTTP app exposes a /health endpoint, and SmartStack's Nerve removes unhealthy backends automatically.
2. Airflow gives a web UI to monitor data pipelines.
3. The full current metrics and alerting stack is not publicly shared in detail.

If we built an app like Airbnb on AWS (illustrative)

Suppose you want to build "KokanStay", a homestay booking app for the Konkan coast. Here is a simple AWS layout.

1. Network: VPC, subnets, route tables, gateways

1. Create one VPC with CIDR 10.0.0.0/16 in the Mumbai region (ap-south-1).
2. Use two Availability Zones (A and B), so one AZ failing does not stop the app.
3. In each AZ make three subnets: public (load balancer, NAT gateway), private app (your code) and private data (databases, cache).
4. Attach one internet gateway (IGW) to the VPC. Public route table: 0.0.0.0/0 → IGW. This route is what makes a subnet public.
5. Private app route table: 0.0.0.0/0 → NAT gateway, so servers can download updates but nobody can connect in from the internet.
6. Private data route table: only the local VPC route. Use VPC endpoints to reach S3, DynamoDB and SQS without going over the internet.

2. Compute: where the code runs

1. ALB in both public subnets.
2. Start with one well-structured app; split out search, booking and payments into services on EKS as the team grows (Airbnb's path).
3. Background workers read SQS for emails and reminders.
4. Schedule nightly data jobs with Amazon MWAA (managed Airflow).

3. Storage and databases

1. S3 + CloudFront for listing photos.
2. Aurora MySQL for listings, users and bookings (Multi-AZ).
3. DynamoDB for availability calendars.
4. ElastiCache for popular search results.

4. Monitoring

1. A /health endpoint on every service, used by ALB health checks.
2. CloudWatch alarms on booking errors and latency.
3. X-Ray to trace a booking across services.

Request flow diagram

Press Play. The numbered list below the diagram lights up with each step.

Airbnb versus our AWS design