Bạn đã viết API, đã deploy lên production, đã fix bug lúc nửa đêm. Nhưng khi cần quyết định “tách service hay giữ monolith”, khi cần chọn giữa Kafka và RabbitMQ, khi database một con không đủ — bạn cần nhiều hơn kinh nghiệm code hàng ngày.
Loạt bài này đi từ ranh giới service đến vận hành ở scale, theo trục “hiểu trade-off để ra quyết định, không chỉ để biết tên pattern”.
Đối tượng
| Bạn là | Bạn sẽ học được |
|---|---|
| Backend engineer (middle+) | Ra quyết định kiến trúc có cơ sở; biết trade-off mỗi pattern; tránh over-engineering. |
| Tech lead / Architect | Review thiết kế nhanh; checklist khi đánh giá proposal; ngôn ngữ chung cho design review. |
Tiền đề: đã build và vận hành ít nhất một service backend trên production. Không cần kinh nghiệm distributed systems trước.
Ba giai đoạn
Giai đoạn I — Ranh giới và giao tiếp
Tách service hay không, và chúng nói chuyện với nhau bằng gì?
- Monolith hay microservice — framework quyết định
- API gateway — routing, auth, rate limit ở một chỗ
- Message queue — Kafka, RabbitMQ, SQS: chọn theo bài toán
- Event-driven — event notification vs event sourcing
Giai đoạn II — Pattern dữ liệu phân tán
Khi dữ liệu nằm ở nhiều nơi, làm sao giữ nhất quán và hiệu năng?
- CQRS — tách đọc ghi khi nào có lợi
- Saga pattern — orchestration vs choreography
- Cache strategy — invalidation là bài toán khó nhất
- Outbox pattern — ghi DB và publish event không mất message
Giai đoạn III — Resilience và vận hành ở scale
Làm sao hệ thống chịu được lỗi, scale được, và không sập lúc nửa đêm?