Stage 1: Monolith (startup)
- Single codebase
- Simple deployment
- Easy to test

Stage 2: Modular Monolith
- Well-defined modules
- Clean separation of concerns
- Still single deployment

Stage 3: Microservices
- Separate services
- Independent scaling
- Team autonomy
- Operational complexity

User API ── Business Logic ── Database
│           │
├─ Auth     ├─ User service
├─ Profile  ├─ Order service
├─ Orders   └─ Payment service
└─ Payments

Load Balancer
    ↓
API Gateway
    ├─ User Service (Node.js)
    ├─ Order Service (Python)
    ├─ Payment Service (Java)
    └─ Notification Service (Go)
    
Each service:
- Own database
- Own deployment
- Own scaling

Don't rewrite everything at once (Amazon failed this way)

Better approach:
- Extract highest pain services first
- Learn from each extraction
- Build expertise gradually
- Keep ability to rollback

Monolith maintenance: $1M/year
Microservices infra: $500K/year (better scaling)
Microservices ops: $2M/year (more complex)
Net cost increase: $1.5M/year

Benefit: Can deploy 100x faster, scale independently
Worth it if: Development bottleneck > ops cost

Order service → synchronously calls → Payment service
             → synchronously calls → Inventory service

If any fails: Roll back all (distributed transaction)

Pros: Strong consistency
Cons: Coupling, cascading failures, complex

Order service publishes "order.created"
  ↓
Payment service listens → charges card
  ↓
Inventory service listens → decrements stock
  ↓
Email service listens → sends confirmation

If payment fails:
  - Publish "order.payment_failed"
  - Inventory, email services react
  
Takes seconds to converge, but eventually consistent

Order service:
  1. Create order (PENDING)
  2. Call payment service
  3. If success → call inventory service
  4. If any fail → compensate (undo previous steps)

Orchestrated saga:
  Order service → tells Payment to charge
             → tells Inventory to decrement
             → handles rollback if needed

Choreography saga:
  Order publishes event → Payment listens, charges
                       → Inventory listens, decrements
                       → Each publishes own events

# Order service
def create_order(user_id, items):
    order = db.create_order(user_id, items, status="PENDING")
    
    # Publish event (async)
    queue.publish("order.created", {
        "order_id": order.id,
        "user_id": user_id,
        "items": items
    })
    
    return order

# Payment service (listens to order.created)
def handle_order_created(event):
    order_id = event['order_id']
    try:
        charge_card(user_id, amount)
        queue.publish("order.payment_succeeded", {"order_id": order_id})
    except PaymentError:
        queue.publish("order.payment_failed", {"order_id": order_id})

# Inventory service (listens to order.payment_succeeded)
def handle_payment_succeeded(event):
    order_id = event['order_id']
    for item in get_order_items(order_id):
        decrement_inventory(item)
    queue.publish("order.inventory_updated", {"order_id": order_id})

API Gateway (routes requests)
    ├─ Video Catalog Service
    │  └─ Get videos, metadata, genres
    │
    ├─ Recommendation Service
    │  └─ ML-powered recommendations
    │
    ├─ User Profile Service
    │  └─ Preferences, watch history, settings
    │
    ├─ Payment Service
    │  └─ Billing, subscriptions, payments
    │
    ├─ Content Delivery Service
    │  └─ Video streaming, adaptive bitrate
    │
    ├─ Notification Service
    │  └─ Email, push, SMS
    │
    ├─ Search Service
    │  └─ Elasticsearch-backed search
    │
    └─ Analytics Service
       └─ User behavior, metrics

Scenario 1: Deploy once per month
- Monolith: 1 deploy × 2 hours = 2 hours downtime/month
- Microservices: 20 deploys × 5 min = 100 min downtime/month
- Microservices WORSE (5x more downtime)

Scenario 2: Deploy 10 times per day
- Monolith: 10 × 2 hours = 20 hours downtime/day (IMPOSSIBLE)
- Microservices: 10 × 5 min = 50 min downtime/day (acceptable)
- Microservices BETTER (enables frequent deployments)

Scenario 3: Deploy independently (ideal)
- Monolith: Can't (all changes together)
- Microservices: Each team deploys independently
  - Team A deploys every hour
  - Team B deploys weekly
  - No coordination needed
- Microservices MUCH BETTER

Microservices operational overhead:
- 15 services × 3 engineers per service = 45 engineers
- Distributed tracing, monitoring, logging
- Incident response (failures in distributed system)
- Total ops cost: $5M/year

Monolith development productivity:
- 50 engineers, but coordination overhead
- Merge conflicts, deployments blocked
- Release cycle: 2 weeks
- Time to market: slow

If: Time to market worth $5M/year → Microservices
If: Operational simplicity matters → Monolith

Netflix answer: Time to market >> ops cost
We'll take the $5M/year to deploy 100x faster