1.1.3 Tightly vs Loosely Coupled

Tightly Coupled vs Loosely Coupled

Tightly coupled là các component phụ thuộc chặt (thường gọi trực tiếp đồng bộ), nên dễ “đứt dây chuyền” khi một mắt xích lỗi; loosely coupled dùng cơ chế trung gian (queue/event bus) để giảm phụ thuộc và cô lập lỗi tốt hơn.

Với AWS, các lựa chọn hay gặp để “decouple” là SQS/SNS/EventBridge; còn Step Functions dùng khi bạn cần điều phối workflow nhiều bước.

Tightly Coupled

Giao tiếp

  • Direct call (HTTP/gRPC), request/response
  • Thường synchronous

Rủi ro

  • ❌ Cascade failure: Service A gọi service B lỗi/timeout → A cũng lỗi hoặc bị treo
  • ❌ Khó deploy độc lập vì contract/API thay đổi kéo theo nhiều bên

Scale

  • Hay phải scale “cả cụm” theo điểm nghẽn (vì phụ thuộc chuỗi gọi nhau)
  • Dù từng service có thể scale riêng nhưng áp lực phối hợp cao

Ví dụ

Order service gọi trực tiếp Payment service; Payment chậm hoặc lỗi sẽ làm Order timeout và gây lỗi lan truyền.

Loosely Coupled

Loosely coupled thường đặt một lớp trung gian để producer “gửi thông điệp/sự kiện”, consumer xử lý bất đồng bộ (async) theo tốc độ riêng, qua đó giảm coupling giữa các component.

Trên AWS

  • SQS: làm hàng đợi giữa producer và consumer
  • SNS: cho pub/sub (fan-out)
  • EventBridge: làm event bus với rule để route events tới nhiều target

Ví dụ

Order service publish “OrderCreated” event → các consumer như Payment, Inventory, Email tự xử lý độc lập.

So sánh nhanh

Tiêu chíTightly coupledLoosely coupled
Giao tiếpDirect calls (sync)Queue / pub-sub / event bus (async)
FailureDễ cascade failuresFailure isolation tốt hơn (consumer lỗi không chặn producer ngay lập tức)
ScalingDễ “đi cùng nhau” theo chuỗi phụ thuộcScale theo từng component/consumer độc lập
LatencyThường thấp hơn cho 1 request end-to-endThường cao hơn (do async + hop trung gian)
ComplexityĐơn giản lúc đầuPhức tạp hơn (retry, idempotency, ordering, quan sát luồng)

Mapping dịch vụ AWS (đúng keyword đề thi)

Nhận diện nhanh từ đề bài:

  • “Decouple components”, “buffer”, “async processing” → SQS (producer/consumer tách rời, consumer có thể pull xử lý theo nhịp riêng)
  • “Fan-out tới nhiều consumer” → SNS topic + (mỗi consumer một SQS queue để xử lý độc lập) hoặc EventBridge route tới nhiều targets
  • “Orchestrate workflow”, “multi-step + retry/timeout/error handling tập trung” → Step Functions (điều phối luồng và quan sát trạng thái theo workflow)