🏘️ Microservices

Small, independent services that do ONE thing well.

Monolith:
  ┌────────────────────────────────────┐
  │           BIG APPLICATION          │
  │  Users + Orders + Payments + ...   │
  └────────────────────────────────────┘

Microservices:
  ┌──────────┐  ┌──────────┐  ┌──────────┐
  │  Users   │  │  Orders  │  │ Payments │
  │ Service  │  │ Service  │  │ Service  │
  └──────────┘  └──────────┘  └──────────┘

Each service:
  - Has its own codebase
  - Has its own database
  - Deploys independently
  - Communicates via API

Each service does ONE thing.

User Service: Manage users
Order Service: Handle orders
Payment Service: Process payments

Not: User-Order-Payment-Everything Service

Each service owns its data.

User DB ─ User Service
Order DB ─ Order Service
Payment DB ─ Payment Service

Avoid sharing databases between services when possible.
Prevents tight coupling.

Services communicate via API.

REST, gRPC, GraphQL, or messaging.

Clear contracts between services.

Deploy User Service without touching Order Service.

Changes are isolated.
Releases are safer.

Order Service → User Service: "Get user 123"
User Service → Order Service: { user data }

Direct call. Wait for response.
Simple. But creates dependency.

Order Service → Message Queue: "Order placed"
User Service ← (subscribed): React to order

No waiting. Decoupled.
More resilient. More complex.

Sync: Need immediate response
Async: Can process later, fire-and-forget

Often: Mix of both.

Deploy 10× a day.
Often, you can deploy just the service that changed.
Fast, lower-risk releases.

User Service: Python
Order Service: Java
Analytics: Go

A good tool for each job.

Payment service under load?
Scale just the payment service.

Don't waste resources on others.

Payment service crashes.
Users can still browse, add to cart.
Graceful degradation.

User team owns User Service.
Order team owns Order Service.

Clear ownership. Faster decisions.

Network calls can fail.
Services can be slow.
Data consistency is hard.

More moving parts = More failure modes.

Order in Order DB.
Inventory in Inventory DB.

How to keep in sync?
Eventual consistency, sagas, events.

Request spans 5 services.
Where did it fail?

Need distributed tracing.

10 services to monitor.
10 deployments to manage.
10 databases to maintain.

Containerization and orchestration help.

✓ Large teams (Amazon's "two-pizza rule")
✓ Complex domains
✓ Different scaling needs
✓ Need technology flexibility
✓ Frequent deployments

Small team? Start monolithic.
Easier to develop, deploy, debug.

Extract microservices when:
  - Team grows
  - Parts need different scaling
  - Deploy frequency differs
  - Clear domain boundaries emerge

"Modular monolith" → Microservices later.

                ┌─────────────┐
                │   Clients   │
                └──────┬──────┘
                       │
                ┌──────▼──────┐
                │ API Gateway │
                └──────┬──────┘
                       │
         ┌─────────────┼─────────────┐
         │             │             │
    ┌────▼────┐  ┌─────▼────┐  ┌─────▼────┐
    │  User   │  │  Order   │  │ Payment  │
    │ Service │  │ Service  │  │ Service  │
    └────┬────┘  └────┬─────┘  └────┬─────┘
         │            │             │
    ┌────▼────┐  ┌────▼─────┐  ┌────▼─────┐
    │ User DB │  │ Order DB │  │Payment DB│
    └─────────┘  └──────────┘  └──────────┘

Containers: Docker
Orchestration: Kubernetes
API Gateway: Kong, AWS API Gateway
Messaging: Kafka, RabbitMQ
Tracing: Jaeger, Zipkin
Monitoring: Prometheus, Grafana
Service Mesh: Istio, Linkerd

100 nano-services for 5 developers?
Operational nightmare.
Start with fewer, larger services.

Services sharing a database = tight coupling.
Change schema → Break multiple services.
Each service needs its own data store.

Service A → B → C → D (all sync)
D slow = the whole request feels slow.
Use async where possible.

Microservices need:
  - Containerization
  - Orchestration
  - Monitoring
  - Logging
  - Tracing

Build platform before services.