Blog 7 — Airbnb: Monolith to Microservices

C

Qubits of DPK

March 21, 2026

Core Case Studies
Source: https://medium.com/airbnb-engineering
Core Concept: Service decomposition, Data ownership between services
Why SDE-2 Critical: Every growing company goes through this — shows architectural maturity in interviews
Status: Draft notes ready

Quick Revision

  • Problem: One monolith slows teams, deployments, and scaling.
  • Core pattern: Domain-based service boundaries with gradual extraction.
  • Interview one-liner: Microservices are an organizational scaling tool, not a default architecture.

️ The Journey

javascript
QUBITS OF DPK
12008: Monolith ("Monorail")
2  └── All code in one Rails app
3  └── One DB, one deployment
4  └── Works great at small scale
5         │
62015-2020: Pain begins
7  └── Deployments take hours
8  └── One bug can down everything
9  └── 500+ engineers stepping on each other
10         │
112020+: Microservices migration
12  └── Services decomposed by domain
13  └── Each team owns their service + DB

Core Concepts

Why Monoliths Break at Scale

javascript
QUBITS OF DPK
1Monolith problems at Airbnb:
2  - 500+ engineers, 1 codebase → merge conflicts daily
3  - Deploy search fix → accidentally breaks payments
4  - One slow query → entire app slows down
5  - Can't scale search independently from messaging
6  - Tech debt accumulates in one giant ball

Service Decomposition Strategy

javascript
QUBITS OF DPK
1Airbnb split by business domain:
2  ├── Search Service        (listing discovery)
3  ├── Booking Service       (reservations)
4  ├── Payments Service      (money)
5  ├── Messaging Service     (host-guest chat)
6  ├── Reviews Service       (ratings)
7  ├── Identity Service      (auth, profiles)
8  └── Notifications Service (email, push, SMS)

Data Ownership Rule

javascript
QUBITS OF DPK
1Each service owns its OWN database.
2Other services CANNOT read it directly.
3
4Booking Service needs user info:
5  ❌ BAD:  SELECT * FROM users_db.users WHERE id = 123
6  ✅ GOOD: GET /identity-service/users/123
7
8Why? If Identity DB schema changes → only Identity Service updates.
9     Booking Service is shielded from the change.

The Strangler Fig Pattern

javascript
QUBITS OF DPK
1Don't rewrite everything at once (too risky).
2Instead:
3  1. New feature? Build as microservice.
4  2. Old feature? Extract when touching it.
5  3. Gradually strangle the monolith.
6  4. Monolith shrinks over years, not months.
7
8Monolith still serves requests →
9  New service handles subset →
10    Gradually more traffic shifts →
11      Monolith retires cleanly

When NOT to Use Microservices

  • Team < 10 engineers → monolith is faster
  • Early product with changing requirements → microservices slow iteration
  • No DevOps culture → microservices need strong infra discipline
  • Distributed transactions needed everywhere → microservices make this painful

Results

5 Interview Questions This Blog Unlocks

Q1. When would you NOT use microservices?

Answer: Small team (< 10 engineers), early-stage product with frequently changing requirements, no strong DevOps culture, or when the domain boundaries aren't clear yet. Microservices add operational complexity — only justified when team/scale demands it.

Q2. How do microservices communicate with each other?

Answer: Synchronous: REST or gRPC (when you need immediate response). Asynchronous: Kafka/RabbitMQ (when you don't need immediate response, better for decoupling). Rule: prefer async when possible — it's more resilient.

Q3. How do you handle a transaction that spans multiple microservices?

Answer: Saga pattern. Each service does its local transaction and publishes an event. Next service listens and continues. If any step fails, compensating events roll back previous steps. Avoid 2-phase commit — it's slow and creates distributed locks.

Q4. What is the Strangler Fig pattern?

Answer: Gradual monolith decomposition. Don't rewrite everything at once (too risky). Instead, incrementally extract functionality into microservices. New features built as microservices. Old code extracted when touched. Monolith shrinks over time without a big-bang rewrite.

Q5. How do you ensure data consistency across microservices without shared databases?

Answer: Each service owns its DB. Consistency achieved through eventual consistency + events. Service A completes its transaction and publishes an event. Service B consumes event and updates its DB. Temporary inconsistency is acceptable in most cases. For strong consistency, use saga with compensating transactions.

Key Engineering Lessons