📚 Chapter 2: Architectural Patterns — Application and Trade-offs

1. Event-Driven Architecture (EDA)

Definition: Services communicate asynchronously by producing and consuming immutable events (facts about something that happened).

A. When to Apply

• Decoupling: Keep services independent; avoid synchronous dependencies.
• Real-time Processing: Propagate changes instantly (fraud detection, inventory updates).
• Auditability: Events provide a historical log — the source of truth.

B. Trade-offs

• Pro: Extreme decoupling, high scalability, strong resilience.
• Con: Complex debugging (no single call stack); handle event schema evolution carefully.

2. CQRS (Command Query Responsibility Segregation)

Definition: Separate the model used for commands (updates) from the model used for queries (reads).

A. When to Apply

• Read/Write Skew: Read volume far exceeds writes; read models need denormalized views.
• Performance: Optimize read side (e.g., non-relational DB) while preserving write integrity.

B. Trade-offs

• Pro: Read performance optimization; independent scaling of read/write databases.
• Con: Introduces eventual consistency; operational complexity maintaining two stores.

3. Saga Pattern

Definition: A sequence of local transactions. Each updates the database and publishes an event to trigger the next step. Failures trigger compensating transactions to undo previous work.

A. When to Apply

• Distributed Transactions: Alternative to 2PC in microservices spanning multiple services (e-commerce order).
• Long-Lived Processes: Workflows running minutes or hours.

B. Implementation Styles

• Choreography: Services subscribe to events and trigger next steps without a coordinator — best for simple Sagas.
• Orchestration: A central orchestrator commands participants — best for complex, many-step Sagas.

4. Strangler Fig Pattern

Definition: Gradually replace a monolith by incrementally retiring functionalities and replacing them with new services.

A. When to Apply

• Monolith Migration: When a full rewrite is impractical.
• Risk Mitigation: Keep legacy stable while developing new features in isolation.

B. How it Works

1. Facade/Proxy: Route traffic through an API Gateway.
2. Intercept: Proxy routes to new service or legacy monolith.
3. Strangulation: Gradually shift routes until the monolith is decommissioned.

5. API Gateway Pattern

Definition: A single entry point for all clients that routes requests to backend services and handles cross-cutting concerns.

A. When to Apply

• Microservices Entry: Simplify client access to many services.
• Cross-Cutting: Centralize auth, rate limiting, SSL termination, transformations.

B. Trade-offs

• Pro: Decouples clients from service structure; simplifies microservice development.
• Con: Single point of failure; potential development bottleneck without proper governance.