SNS (Simple Notification Service) P1

Tích hợp trực tiếp (Direct integration)
- Buying Service gửi trực tiếp đến:
  - Email notification
  - Fraud Service
  - Shipping Service
  - SQS Queue
- Vấn đề khi sử dụng tích hợp trực tiếp:
  - Tăng độ phụ thuộc giữa các service (tight coupling):
    Buying Service phải biết chính xác từng thành phần downstream mà nó cần gửi message. Điều này khiến nó gắn chặt logic xử lý với từng consumer cụ thể.
  - Thiếu tính mở rộng (scalability kém):
    Khi có thêm một consumer mới cần xử lý thông điệp (ví dụ thêm SMS Notification), bạn buộc phải chỉnh sửa Buying Service → vi phạm nguyên tắc đóng/mở (Open/Closed Principle).
  - Phức tạp trong xử lý lỗi và retry:
    Nếu Fraud Service bị lỗi hoặc Email Service down, bạn phải viết thêm logic retry cho từng phần, khiến mã nguồn Buying Service trở nên cồng kềnh và dễ lỗi.
  - Bảo trì khó khăn:
    Code gắn kết giữa producer và các consumer dẫn đến chi phí bảo trì cao, khó kiểm thử độc lập từng phần.

Mô hình Pub/Sub (Publish/Subscribe)
- Buying Service gửi message đến một SNS Topic
- SNS Topic sẽ phân phối message đến:
  - Email notification
  - Fraud Service
  - Shipping Service
  - SQS Queue

“Event producer” chỉ gửi message đến một SNS Topic duy nhất
Có thể có nhiều “event receivers” (các subscription) lắng nghe các notification từ SNS Topic
Mỗi subscriber sẽ nhận toàn bộ message từ topic

Lưu ý: đã có tính năng mới để lọc message cho từng subscriber

Nhiều service của AWS có thể gửi dữ liệu trực tiếp đến SNS để phục vụ mục đích notification (thông báo).

Cách publish message
- Topic Publish (sử dụng SDK):
  - Tạo một topic
  - Tạo một hoặc nhiều subscription
  - Gửi (publish) message tới topic
    → Phù hợp cho các kiến trúc event-driven, decoupling logic.
- Direct Publish (dành cho SDK ứng dụng di động):
  - Tạo một platform application
  - Tạo một platform endpoint
  - Gửi message tới endpoint đó
  - Hỗ trợ các dịch vụ như: Google GCM, Apple APNS, Amazon ADM, ...
    → Dùng cho việc gửi tin nhắn cá nhân hóa tới thiết bị di động qua các dịch vụ push notification của các nền tảng khác nhau

SNS có retry và đảm bảo “at least once” delivery
Nếu SNS publish message tới subscriber (ví dụ SQS queue, Lambda, HTTP endpoint), mà endpoint đó bị lỗi hoặc timeout, SNS sẽ retry trong khoảng thời gian ngắn (vài phút).
Điều này đảm bảo rằng nếu lỗi tạm thời (network chập chờn), message vẫn có cơ hội được delivery lại → "at least once".
Nhưng nếu sau một số lần retry mà subscriber vẫn không khả dụng, thì:
- SNS sẽ drop message đó (tức là không retry mãi mãi).
- Nếu bạn cấu hình Dead Letter Queue (DLQ) cho SNS thì message sẽ được gửi vào đó.
⛔ Nghĩa là SNS không lưu trữ message, không có cơ chế như “pull lại sau 1 giờ” hay “retry trong 3 ngày” như SQS.

Encryption
- Mã hoá dữ liệu khi truyền (in-flight) sử dụng API HTTPS
- Mã hoá dữ liệu khi lưu trữ (at-rest) sử dụng khóa KMS
- Mã hoá phía client nếu client muốn tự xử lý mã hoá/giải mã
Kiểm soát truy cập (Access Controls):
- Sử dụng chính sách IAM để kiểm soát quyền truy cập API của SNS
Chính sách truy cập SNS (SNS Access Policies) (tương tự với chính sách bucket S3):
- Hữu ích cho việc truy cập SNS từ tài khoản khác (cross-account)
- Hữu ích cho việc cho phép các dịch vụ khác (ví dụ: S3) ghi dữ liệu vào SNS topic