Tuần 10 - Ngày 4: Decoupled Architectures

Mục tiêu học tập

• Hiểu coupling vs decoupling
• Apply SQS/SNS/EventBridge cho decouple
• Microservices patterns
• Async vs sync trade-offs

1. Coupling Concepts

Tightly Coupled (bad)

• Components depend on each other directly
• 1 fails → others fail
• Hard to scale, change, deploy

Loosely Coupled (good)

• Components communicate via interfaces (API, queue, event)
• Failures isolated
• Independent scaling, deployment
• More resilient

Example

TIGHTLY COUPLED:
Web Server → calls Order Processor (synchronous HTTP)
   ↓
If Order Processor down → Web Server can't respond → User error

LOOSELY COUPLED:
Web Server → SQS Queue → Order Processor (async)
   ↓
Web Server returns 202 (accepted), Order Processor down → message waits in queue

2. Decoupling Strategies

Sync to Async (via Queue)

BEFORE: Client → Service A → Service B → Service C (sync chain)
AFTER:  Client → Service A → Queue → Service B → Queue → Service C

Service mesh / Event-driven

Service A publishes event → Event Bus
                          → Service B subscribes
                          → Service C subscribes
                          → Service D subscribes

Benefits

• Independent scaling (Service B slow, Service A unaffected)
• Buffer for spikes (queue absorbs)
• Easier to add/remove services
• Independent deploys
• Better testability

3. AWS Decoupling Tools

4. SQS-based Decoupling

Pattern: Producer-Consumer

Web App (producer)
   ↓ (send message)
SQS Queue
   ↓ (poll)
ASG of Workers (consumers)

Benefits

• Web App scales independently from Workers
• Buffer (sudden spike → queue grows, workers catch up)
• Workers can be EC2, Lambda, Fargate
• DLQ for failed messages

Example: Order processing

User submits order → API Gateway → Lambda
                                    ↓
                            SQS Queue (orders)
                                    ↓
                            ASG of Order Processors
                                    ↓
                            Update DynamoDB + send email via SES

5. SNS-based Fanout

Pattern: 1 event → N consumers

Each consumer independent. Add new consumer? Just add SQS + service.

6. Event-Driven với EventBridge

Pattern: Multiple sources, smart routing

Use case: Multi-team SaaS

• Each team subscribes to events they need
• Centralized event hub
• Schema Registry for governance

7. Microservices Decoupling

Architecture

Communication patterns

Synchronous (HTTP/REST)

• Use case: real-time response needed
• Trade-off: tight coupling

Asynchronous (events)

• Use case: eventual consistency OK
• Trade-off: complexity but resilient

Best practice

• Sync between services where response immediate needed
• Async for side effects (notification, analytics)

8. Saga Pattern (Distributed Transactions)

Vấn đề

• Microservices each own database
• Distributed transaction (e.g., book trip = hotel + flight + payment)
• No 2-phase commit in distributed systems

Saga solution

• Series of local transactions
• If 1 fails → compensating actions for previous

Example

Book Trip:
1. Reserve Hotel → success
2. Book Flight → success
3. Charge Payment → FAILED!

Compensating:
3. (no-op)
2. Cancel Flight booking
1. Cancel Hotel reservation

Implementation

• Step Functions: orchestrate saga (centralized)
• Choreography (Events): each service listens, reacts (decentralized)

9. CQRS Pattern (Command Query Responsibility Segregation)

Định nghĩa

Separate write model (commands) from read model (queries).

Architecture

Write Path:
Client → Command → Aurora (writes)
                    ↓
              DynamoDB Streams / CDC
                    ↓
              Update read model

Read Path:
Client → Query → OpenSearch / DynamoDB / Cache (optimized reads)

Benefits

• Read + Write scale independently
• Use right tool for each (Aurora for writes, OpenSearch for searches)
• Read model can be denormalized for speed

10. Event Sourcing

Định nghĩa

Store events (not just current state). Replay events to reconstruct state.

Example

Bank account events:
1. AccountCreated(id=123)
2. Deposit($100)
3. Withdraw($30)
4. Deposit($50)

Current balance = sum of events = $120

Store all events in DynamoDB Streams or Kinesis

Benefits

• Full audit trail
• Time travel debugging
• Replay for new consumers
• Eventual consistency natural

AWS Implementation

• Events: DynamoDB / Kinesis / EventBridge
• Replay: Step Functions with Distributed Map

11. Async API Pattern

Vấn đề

• Long-running task (image processing, ML inference)
• Sync HTTP times out

Solution: Async API

1. Client → POST /jobs → API Gateway
2. API Gateway → SQS Queue
3. Lambda invoked, returns job_id (202 Accepted)
4. Worker processes job → updates status
5. Client polls GET /jobs/{id} or
   Client uses WebSocket / SNS notification when done

12. Common Patterns

Pattern 1: Image processing pipeline

User uploads image → S3
                      ↓ (event)
                    Lambda thumbnail generator
                      ↓
                    Save thumbnail → S3
                      ↓ (event)
                    EventBridge → Notification + Search index update

Pattern 2: E-commerce order

Pattern 3: IoT data

Pattern 4: Workflow orchestration

Câu hỏi ôn tập

1. Tightly coupled vs loosely coupled khác nhau ở điểm gì?

   Xem đáp án

   Tightly coupled: services gọi nhau trực tiếp synchronously — failure của 1 service cascade đến services khác, scaling của 1 service bị ràng buộc bởi service khác. Loosely coupled: services communicate qua message broker (SQS, SNS, EventBridge) — sender không biết receiver, receiver scale độc lập, failure của 1 service không crash caller. Loose coupling tăng resilience, scalability, và maintainability.

2. Khi nào dùng SNS thay vì SQS?

   Xem đáp án

   SNS khi cần broadcast same message đến nhiều consumers (fanout) — SNS push đến tất cả subscribers cùng lúc. SQS khi chỉ 1 consumer nhận mỗi message, hoặc cần queue buffer, hoặc cần persistence/retry. Pattern phổ biến: SNS + SQS fanout — SNS broadcast → nhiều SQS queues, mỗi queue cho một consumer service — kết hợp ưu điểm cả hai. Khi cần email/SMS/HTTP webhook: dùng SNS.

3. Saga Pattern giải quyết vấn đề gì?

   Xem đáp án

   Saga Pattern giải quyết distributed transactions trong microservices — không thể dùng 2-phase commit across services. Saga chia transaction lớn thành chuỗi local transactions với compensating transactions để rollback nếu step nào fail. Hai loại: Choreography (services tự react đến events, không có central coordinator) và Orchestration (Step Functions điều phối sequence). Đảm bảo eventual consistency thay vì ACID transactions.

4. CQRS giải quyết vấn đề gì?

   Xem đáp án

   Command Query Responsibility Segregation tách write model (Commands) khỏi read model (Queries). Giải quyết: (1) Write và read có performance requirements khác nhau — scale độc lập, (2) Read model có thể được optimize riêng (denormalized, pre-computed views), (3) Complex queries không ảnh hưởng write throughput. Ví dụ: DynamoDB cho writes + Elasticsearch cho search, hoặc RDS cho writes + read replicas được cache.

5. Async API pattern dùng cho use case nào?

   Xem đáp án

   Async API phù hợp cho long-running operations (> 10 giây) mà không muốn client đợi: video processing, image resize, report generation, ML inference, email sending. Pattern: (1) Client gửi request → API GW → SQS/Lambda → trả 202 Accepted với jobId, (2) Client poll status endpoint hoặc nhận webhook callback khi xong. Tránh HTTP timeout, giảm resource hold, cho phép retry và DLQ.

Bài tập thực hành

• Build pipeline: API Gateway → SQS → Lambda → DynamoDB
• Add SNS fanout: API → SQS + Lambda + email
• Implement Step Functions saga: 3 steps with error handlers
• Setup async API: submit job → return job_id → poll status
• Vẽ architecture diagram cho 1 microservices app

Tài liệu tham khảo chính thức

• Decoupled Architectures Whitepaper
• Saga Pattern
• Event-Driven Architecture

---

Tiếp theo: Serverless Patterns