1.1.1 Architectural Patterns
Architectural Patterns (Khung tổng quát)
Trong kiến trúc hiện đại trên AWS, 3 “nhóm pattern” hay gặp nhất trong đề thi là:
- Event-driven: giao tiếp bằng sự kiện
- Microservices: chia nhỏ theo domain
- Monolithic: 1 khối triển khai
Điểm khác nhau cốt lõi nằm ở cách kết dính (coupling), cách mở rộng (scaling), và cách quan sát/trace/debug khi chạy phân tán qua network.
Chọn SNS/SQS/EventBridge nhanh
Bảng dưới là “rule-of-thumb” theo mô tả chính thức AWS:
| Dịch vụ | Mô hình giao tiếp | Lưu/persist dữ liệu | Dùng tốt khi |
|---|---|---|---|
| SQS | Pull-based (consumer poll) | Message persist đến khi consume/expire | Buffer/decouple, xử lý async, “đệm” tốc độ giữa các service |
| SNS | Push-based pub/sub | Không persist, chuyển real-time tới subscriber | Fan-out notification, pub/sub đơn giản tới nhiều subscriber |
| EventBridge | Rule-based event bus, route theo pattern | Không persist, xử lý real-time | Event-driven + routing theo nội dung, tích hợp nhiều nguồn/target |
Event-Driven Architecture
Event-driven nghĩa là “producer phát event”, còn “consumer phản ứng và xử lý”, và Lambda coi “event” là bất cứ thứ gì kích hoạt function chạy (push trực tiếp hoặc pull qua event source mapping).
Trigger điển hình
- API Gateway (HTTP request)
- EventBridge rule (schedule hoặc event pattern)
- S3 event (object changes)
- Lambda pull message từ SQS thông qua event source mapping
Trade-off quan trọng
- ✅ Loosely coupled, scalable
- ❌ Độ trễ biến thiên do giao tiếp qua network
- ❌ Debug khó hơn monolith vì log/trace nằm rải rác theo từng service/function
Microservices vs Monolithic
Microservices
- Giúp giảm độ phức tạp bằng cách tách workflow lớn thành các service nhỏ
- Ví dụ: tách ecommerce monolith thành:
- Order acceptance
- Payment
- Inventory
- Fulfillment
- Accounting
- Các service giao tiếp bất đồng bộ bằng events
Cảnh báo “Lambda monolith”
AWS cảnh báo việc dồn mọi logic vào 1 function làm:
- ❌ Tăng package size
- ❌ Khó áp dụng least-privilege
- ❌ Khó upgrade/maintain/test
Hướng khuyến nghị: Tách thành các microservice nhỏ, mỗi Lambda làm một nhiệm vụ rõ ràng.
Database-per-service pattern
- Mỗi microservice có datastore riêng
- Service khác không truy cập trực tiếp, chỉ truy cập qua API
- Đổi schema của 1 service không làm ảnh hưởng service khác
- Tăng resilience
Choreography vs Orchestration
Choreography (Phi tập trung)
- Các service tự phản ứng theo event, không có “nhạc trưởng” điều phối
- ✅ Tạo loose coupling
- ✅ Dễ thêm consumer mới
- ❌ Khó debug, khó theo dõi flow end-to-end
- Ví dụ: SNS → multiple SQS queues → multiple Lambda
Orchestration (Tập trung)
- Có một bộ điều phối giữ state/điều khiển thứ tự các bước
- ✅ Dễ theo dõi trạng thái end-to-end
- ✅ Retry/timeout/compensation tập trung
- ✅ Giảm custom code điều phối
- ❌ Single point of failure, tightly coupled
- Ví dụ: AWS Step Functions
Gợi ý dùng nhanh
| Tình huống | Chọn |
|---|---|
| Flow linh hoạt, nhiều team thêm/bớt consumer, ưu tiên loose coupling | Choreography |
| Flow nhiều bước, cần quan sát trạng thái end-to-end, cần retry/timeout tập trung | Orchestration |
Step Functions còn có thể được dùng để “mô tả một choreography như một state machine”, đợi event qua callback pattern, và dùng Choice state để điều hướng theo payload của event.
Fan-out Pattern (1 → nhiều consumers)
Fan-out là một trường hợp điển hình của event-driven: một sự kiện phát ra nhưng nhiều consumer cùng nhận để xử lý các nhánh độc lập.
Biến thể phổ biến trên AWS
- SNS topic fan-out tới nhiều subscriber
- Nếu muốn “mỗi consumer có hàng đợi riêng để xử lý async” → SNS → nhiều SQS queues
- EventBridge route cùng một loại event tới nhiều target dựa theo rule/pattern matching
Exam Tips (Mẹo làm đề, dạng keyword)
Nhận diện nhanh từ đề bài:
- “Decouple”, “buffer”, “async processing” → nghĩ SQS trước
- “Pub/sub”, “fan-out” → SNS
- “Routing theo nội dung”, “event bus” → EventBridge
- “Orchestrate workflow”, “stateful flow”, “retry/timeout tập trung” → Step Functions