Real-World Microservices Case Studies

How the world's largest companies decomposed monoliths, what worked, what failed, and what you can learn from their $billion experiments.

Netflix — The Pioneer

The Trigger: 2008 Database Corruption

In August 2008, Netflix experienced a major database corruption that took down their DVD shipping service for three days. The single Oracle database was a single point of failure for the entire company.

The Migration (2009-2016)

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Before["2008: Monolith"]
        M[("Single Oracle DB")] --> App["One Java App<br/>(millions of LOC)"]
    end

    subgraph During["2009-2012: Strangler"]
        GW{{"API Gateway (Zuul)"}} --> Old["Legacy Monolith<br/>(shrinking)"]
        GW --> New1["Streaming Service"]
        GW --> New2["Recommendation Service"]
        GW --> New3["User Service"]
    end

    subgraph After["2016: Fully Distributed"]
        GW2{{"Zuul 2.0"}} --> S1["700+ Services"]
        S1 --> DB1[("Cassandra")]
        S1 --> DB2[("DynamoDB")]
        S1 --> DB3[("MySQL")]
    end

    Before -->|"3-day outage"| During
    During -->|"7 years"| After

    style M fill:#FFCDD2,stroke:#C62828,color:#000
    style After fill:#E8F5E9,stroke:#2E7D32,color:#000

Netflix OSS Stack

Key Lessons from Netflix

1. Build for failure — In a distributed system, failure is inevitable. Design every service to handle its dependencies being down.
2. Chaos Monkey — "The best way to avoid failure is to fail constantly." Netflix randomly kills production instances to ensure resilience.
3. Each team owns their service end-to-end — Build, deploy, monitor, and get paged at 3am.
4. Freedom with responsibility — Teams choose their own tech stack, but must meet platform-level SLAs.

Uber — Scale at Speed

The Problem

Uber started as a monolithic Python application. By 2014, with exponential growth, the monolith couldn't scale: - Single deployment took hours and blocked all teams - A bug in the receipts feature could crash the trip-matching system - The codebase was so large, new engineers took months to become productive

DOMA: Domain-Oriented Microservice Architecture

After splitting into ~4000+ microservices, Uber found the opposite problem — too many services, too much complexity. They introduced DOMA in 2020:

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart TD
    subgraph Gateway["Gateway Layer"]
        AG[/"API Gateway"/]
    end

    subgraph Domains["Domain Layer (bounded contexts)"]
        D1["Rides Domain<br/>(matching, pricing, routing)"]
        D2["Payments Domain<br/>(billing, refunds, payouts)"]
        D3["Eats Domain<br/>(restaurants, delivery, menus)"]
        D4["Maps Domain<br/>(navigation, ETA, geocoding)"]
    end

    subgraph Platform["Platform Layer (shared infra)"]
        P1["Storage Platform"]
        P2["Messaging Platform"]
        P3["Observability"]
    end

    AG --> Domains
    Domains --> Platform

    style D1 fill:#E8F5E9,stroke:#2E7D32,color:#000
    style D2 fill:#FEF3C7,stroke:#D97706,color:#000
    style D3 fill:#E3F2FD,stroke:#1565C0,color:#000
    style D4 fill:#F3E5F5,stroke:#6A1B9A,color:#000

Key Lessons from Uber

Amazon — The Two-Pizza Team

The Bezos API Mandate (2002)

This single mandate restructured Amazon's entire engineering organization and eventually led to AWS.

Conway's Law in Action

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart LR
    subgraph Org["Organization Structure"]
        T1["Catalog Team<br/>(2-pizza)"]
        T2["Cart Team<br/>(2-pizza)"]
        T3["Payment Team<br/>(2-pizza)"]
        T4["Fulfillment Team<br/>(2-pizza)"]
    end

    subgraph Arch["System Architecture"]
        S1["Catalog Service"]
        S2["Cart Service"]
        S3["Payment Service"]
        S4["Fulfillment Service"]
    end

    T1 ---|"owns"| S1
    T2 ---|"owns"| S2
    T3 ---|"owns"| S3
    T4 ---|"owns"| S4

    S1 <-->|"API"| S2
    S2 <-->|"API"| S3
    S3 <-->|"API"| S4

    style Org fill:#E3F2FD,stroke:#1565C0,color:#000
    style Arch fill:#E8F5E9,stroke:#2E7D32,color:#000

Key Lessons from Amazon

1. "You build it, you run it" — Teams that write code also deploy it AND carry the pager. This creates accountability.
2. Two-pizza teams (6-10 people) — Small teams move faster and communicate better. Team size drives service boundaries.
3. APIs as contracts — Every internal interface is designed as if it were public. This discipline led to AWS existing.
4. Decentralized data ownership — Each service owns its database. No shared databases between teams.
5. Cell-based architecture — Services deployed in isolated "cells" to limit blast radius. One cell failure doesn't affect others.

Spotify — Squad Model

Organization = Architecture

%%{init: {'theme': 'base', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'Inter, -apple-system, sans-serif'}, 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 50, 'padding': 12, 'curve': 'basis'}, 'sequence': {'actorMargin': 60, 'messageMargin': 40}, 'class': {'padding': 12}}}%%
flowchart TD
    subgraph Tribe["Tribe: Music Experience"]
        SQ1["Squad: Playback<br/>→ Playback Service"]
        SQ2["Squad: Discover<br/>→ Recommendation Service"]
        SQ3["Squad: Playlist<br/>→ Playlist Service"]
    end

    subgraph Chapter["Chapter: Backend Engineers"]
        CH["Shared practices<br/>across squads"]
    end

    SQ1 & SQ2 & SQ3 -.-> CH

    style Tribe fill:#E8F5E9,stroke:#2E7D32,color:#000

Key Lessons from Spotify

Cross-Company Comparison

Universal Lessons

What Always Works

1. Start with a monolith — Almost every success story started monolithic and decomposed later. Premature microservices are a recipe for failure.
2. Organizational structure drives architecture (Conway's Law) — If your team structure doesn't match your service boundaries, you'll fight friction forever.
3. Invest in platform/developer experience — Every company that succeeded built internal tools, service templates, and observability platforms.
4. Incremental migration (Strangler Fig) — Big-bang rewrites fail. Gradually route traffic from old to new.
5. Own what you build — The team that writes the code deploys and monitors it.

What Always Fails

1. "Distributed monolith" — Services that deploy together, share databases, or require coordinated releases give you the worst of both worlds.
2. Too many services too fast — Uber's 4000 services proved that micro in "microservices" doesn't mean tiny. Group by domain.
3. Shared databases — The moment two services share a database, you lose independent deployability.
4. Ignoring operational readiness — Without CI/CD, observability, and on-call culture, microservices multiply your operational burden.
5. Copying Netflix at 10 engineers — These companies had thousands of engineers and years to build platform tooling. Context matters.

Interview Application

How to Use These Stories in Interviews