Microservices
Chapter 12: Microservices Architecture
Section titled “Chapter 12: Microservices Architecture”Building Distributed Systems at Scale
Section titled “Building Distributed Systems at Scale”12.1 What are Microservices?
Section titled “12.1 What are Microservices?”Microservices architecture is an approach to software development where an application is built as a collection of small, independent services that communicate over well-defined APIs.
Monolith vs Microservices =========================
MONOLITH: +---------------------------------------------------+ | User | Order | Payment | Notification | Product| +---------------------------------------------------+
MICROSERVICES: +--------+ +--------+ +--------+ +--------+ | User | | Order | |Payment | |Product | | Service| | Service| |Service | |Service | +--------+ +--------+ +--------+ +--------+ | | | | +------------+------------+------------+ | v +-----------------------------------------------+ | Communication Fabric | | (API Gateway, Service Discovery) | +-----------------------------------------------+12.2 Key Characteristics
Section titled “12.2 Key Characteristics”12.2.1 Service Independence
Section titled “12.2.1 Service Independence” Each Service is Independent ==========================
Service A Service B Service C +--------+ +--------+ +--------+ | Deploy | | Deploy | | Deploy | | Update | | Update | | Update | | Scale | | Scale | | Scale | +--------+ +--------+ +--------+ | | | v v v Can be down Can be down Can be down independently independently independently12.2.2 Own Their Data
Section titled “12.2.2 Own Their Data” Database Per Service ===================
User Service Order Service Payment Service +--------+ +--------+ +--------+ | PostgreSQL | PostgreSQL | PostgreSQL | (Users DB) | (Orders DB) | (Payments DB) +--------+ +--------+ +--------+
Benefits: - Loose coupling - Independent scaling - Technology flexibility - Failure isolation12.3 Service Communication
Section titled “12.3 Service Communication”12.3.1 Synchronous Communication (REST/gRPC)
Section titled “12.3.1 Synchronous Communication (REST/gRPC)” Synchronous Communication =========================
Client API Gateway User Service | | | | Request | | |------------->| | | | Forward | | |----------------->| | | | | | Response | | |<-----------------| | Response | | |<-------------| |
Example: GET /api/users/123/orders12.3.2 Asynchronous Communication (Message Queues)
Section titled “12.3.2 Asynchronous Communication (Message Queues)” Asynchronous Communication =========================
Order Service Message Queue Inventory Service | | | | Publish "Order | | | Created" event | | |---------------------->| | | | Deliver message | | |----------------------->| | Return "Order | | | Accepted" | | |<----------------------| | Process asynchronously (can be slow)12.4 API Gateway
Section titled “12.4 API Gateway”Role of API Gateway
Section titled “Role of API Gateway” API Gateway ===========
+--------------------------------------------------+ | API Gateway | +--------------------------------------------------+ | - Request routing | | - Authentication | | - Rate limiting | | - Protocol translation | | - Response aggregation | | - Logging | +--------------------------------------------------+ | | | | v v v v +----+ +----+ +----+ +----+ |User| |Order| |Pay | |Prod| |Svc | |Svc | |Svc | |Svc | +----+ +----+ +----+ +----+
Popular API Gateways: - Kong - NGINX - AWS API Gateway - Apigee - Traefik12.5 Service Discovery
Section titled “12.5 Service Discovery”How Services Find Each Other
Section titled “How Services Find Each Other” Service Discovery =================
+--------------------------------------------------+ | Service Registry | +--------------------------------------------------+ | Service A: 10.0.1.5:8080 | | Service B: 10.0.1.6:8080 | | Service B: 10.0.1.7:8080 | +--------------------------------------------------+
Service A wants to call Service B:
1. Query Registry: "Where is Service B?" 2. Registry returns: "10.0.1.6:8080" 3. Service A calls: http://10.0.1.6:8080
Tools: - Consul - Eureka - etcd - Kubernetes DNS12.6 Advantages of Microservices
Section titled “12.6 Advantages of Microservices”Benefits
Section titled “Benefits”| Advantage | Description |
|---|---|
| Independent Deployment | Deploy services separately |
| Technology Diversity | Use different tech stacks |
| Fault Isolation | Failure doesn’t cascade |
| Scalability | Scale individual services |
| Team Autonomy | Teams own their services |
| Faster Development | Smaller codebases |
12.7 Challenges of Microservices
Section titled “12.7 Challenges of Microservices”Complexities
Section titled “Complexities”| Challenge | Description |
|---|---|
| Distributed Systems | Network failures, latency |
| Data Consistency | Transactions across services |
| Testing | Integration harder |
| Debugging | Distributed tracing needed |
| Operations | More infrastructure |
| Service Contracts | API versioning |
The Challenges Visualized
Section titled “The Challenges Visualized” Microservices Challenges =======================
1. Network Calls +--------------------------------------------------+ | Service A -----> Service B -----> Service C | | | | | | | Latency Timeout Retry | +--------------------------------------------------+
2. Data Consistency +--------------------------------------------------+ | Order Service Inventory Service | | Deduct item Update stock | | But if fails? But if fails? | | Must compensate! Must rollback! | +--------------------------------------------------+
3. Debugging +--------------------------------------------------+ | Trace: Request-123 | | User -> API -> Auth -> Order -> Inventory | | Need distributed tracing! | +--------------------------------------------------+12.8 Designing Microservices
Section titled “12.8 Designing Microservices”12.8.1 Bounded Context
Section titled “12.8.1 Bounded Context” Bounded Contexts ================
E-commerce Domain
+--------------------------------------------------+ | | | +----------+ +----------+ +----------+ | | | User | | Order | |Product | | | | Context | | Context | | Context | | | +----------+ +----------+ +----------+ | | | | | | | +----------------+----------------+ | | Shared Kernel | | (Customer ID format) | +--------------------------------------------------+
Each context = Potential microservice12.8.2 Service Decomposition
Section titled “12.8.2 Service Decomposition” Decomposition Strategies =======================
1. By Business Capability +--------------------------------------------------+ | User | Order | Payment | Shipping | | Service | Service | Service | Service | +--------------------------------------------------+
2. By Subdomain (DDD) +--------------------------------------------------+ | Customer | Order | Billing | Warehouse | | Domain | Domain | Domain | Domain | +--------------------------------------------------+
3. By Use Case +--------------------------------------------------+ | View- | Create- | Update- | Search- | | Order | Order | Order | Product | +--------------------------------------------------+12.9 Inter-Service Communication Patterns
Section titled “12.9 Inter-Service Communication Patterns”12.9.1 Circuit Breaker
Section titled “12.9.1 Circuit Breaker” Circuit Breaker Pattern =======================
Normal State: Service A -----> Service B (working) [Circuit: CLOSED]
Failure State: Service A -----> Service B (timeout) [Circuit: OPEN - fast fail]
Recovery: [Circuit: HALF-OPEN - test periodically]12.9.2 Retry with Backoff
Section titled “12.9.2 Retry with Backoff” Retry Pattern =============
Attempt 1: ------> X (fail) Wait 100ms
Attempt 2: ------> X (fail) Wait 200ms
Attempt 3: ------> X (fail) Wait 400ms
Attempt 4: ------> ✓ (success!)
Techniques: - Exponential backoff - Jitter (randomization) - Circuit breaker12.10 Container Orchestration
Section titled “12.10 Container Orchestration”Kubernetes for Microservices
Section titled “Kubernetes for Microservices” Kubernetes Architecture ======================
+--------------------------------------------------+ | Kubernetes Cluster | +--------------------------------------------------+
Control Plane: +--------------------------------------------------+ | API Server | Scheduler | Controller | etcd | +--------------------------------------------------+
Worker Nodes: +----------+ +----------+ +----------+ | Node 1 | | Node 2 | | Node 3 | +----------+ +----------+ +----------+ | Pod: A | | Pod: B | | Pod: C | | Pod: D | | Pod: E | | Pod: F | +----------+ +----------+ +----------+
K8s handles: - Deployment - Scaling - Service discovery - Load balancing12.11 When to Use Microservices
Section titled “12.11 When to Use Microservices”Good Fit
Section titled “Good Fit”| Scenario | Why Microservices |
|---|---|
| Large teams | Independent team ownership |
| Complex domains | Clear bounded contexts |
| High scale needs | Independent scaling |
| Multiple platforms | Different tech stacks |
| Rapid iteration | Independent deploys |
When NOT to Use
Section titled “When NOT to Use”| Scenario | Why Monolith |
|---|---|
| Small teams | Complexity overhead |
| Simple domain | Over-engineering |
| Startup/MVP | Move fast, iterate |
| Limited scale | Don’t need distribution |
Summary
Section titled “Summary”Key microservices concepts:
- Independent services - Deploy, scale, fail independently
- Own their data - Database per service
- Communication - Sync (REST/gRPC) or async (messages)
- API Gateway - Entry point, routing, auth
- Service Discovery - Find services dynamically
- Complex but powerful - Trade-off complexity for flexibility
- Start with monolith - Extract when needed