Tích hợp ứng dụng và tách rời thành phần
SQS, SNS, EventBridge, Step Functions, API Gateway: tách rời để chịu tải, chịu lỗi và mở rộng độc lập.
- DomainThiết kế chịu lỗi
- DomainThiết kế hiệu năng cao
- 9 sơ đồ
- 10 tình huống
- 11 dịch vụ
5 phút phải nhớ
- Tách rời (decoupling) = đặt hàng đợi hoặc bus sự kiện giữa hai thành phần để bên này chậm hay hỏng không kéo bên kia.Câu đề có "đột biến tải", "không được mất request", "thành phần xử lý chậm" thường cần SQS ở giữa.
- SQS là hàng đợi kéo (pull): consumer tự hỏi lấy tin; mỗi tin chỉ một consumer xử lý rồi xoá.Không phải broadcast. Muốn một tin tới nhiều nơi: SNS fan-out hoặc EventBridge.
- SQS Standard: gần như không giới hạn thông lượng, giao ít nhất một lần, thứ tự không đảm bảo. FIFO: đúng thứ tự trong mỗi message group, không trùng (dedup 5 phút).Consumer của Standard phải idempotent vì tin có thể tới hai lần.
- Visibility timeout: tin đang xử lý bị ẩn (mặc định 30 giây, tối đa 12 giờ); xử lý xong phải DeleteMessage, không thì tin hiện lại.Xử lý lâu hơn visibility timeout → tin bị xử lý trùng. Tăng timeout hoặc gọi ChangeMessageVisibility.
- Dead-letter queue (DLQ): tin nhận quá maxReceiveCount lần mà vẫn lỗi thì chuyển sang DLQ để xem riêng.Tránh một tin hỏng (poison message) bị xử lý lại mãi; có redrive để đưa tin từ DLQ về queue gốc.
- Long polling (WaitTimeSeconds tối đa 20 giây) giảm số lần nhận rỗng, giảm chi phí.Đề hỏi "giảm số API call / chi phí SQS khi hàng đợi thường trống": bật long polling.
- SNS là pub/sub đẩy (push): một tin publish tới topic được gửi tới mọi subscriber (SQS, Lambda, HTTP, email, SMS…).SNS + nhiều SQS = fan-out: mỗi hệ thống có hàng đợi riêng, xử lý độc lập, không mất tin khi consumer tạm chết.
- EventBridge: bus sự kiện có luật lọc theo nội dung, nhận sự kiện từ dịch vụ AWS, ứng dụng SaaS và app của bạn.Phản ứng khi tài nguyên AWS đổi trạng thái (EC2 dừng, GuardDuty phát hiện…) hoặc nhận sự kiện từ SaaS: EventBridge, không phải SNS.
- Step Functions điều phối nhiều bước có retry, catch, chờ, chạy song song. Standard chạy tới 1 năm, đúng một lần; Express tối đa 5 phút, cho khối lượng lớn.Quy trình nhiều bước, cần biết đang ở bước nào và xử lý lỗi từng bước: Step Functions thay vì Lambda gọi Lambda.
- API Gateway: cửa HTTP/REST/WebSocket trước Lambda hoặc backend, có throttling, cache (REST), xác thực, usage plan.Mặc định 10.000 request/giây mỗi tài khoản mỗi Region; integration timeout mặc định tối đa 29 giây.
- Amazon MQ là ActiveMQ / RabbitMQ được quản lý, nói các giao thức chuẩn (JMS, AMQP, MQTT, STOMP, OpenWire).Đưa ứng dụng đang dùng message broker chuẩn lên AWS mà không sửa code: Amazon MQ. Xây mới trên AWS: SQS / SNS.
- Kinesis Data Streams: luồng dữ liệu có thứ tự theo shard, nhiều consumer đọc lại được trong thời gian lưu giữ.Nhiều ứng dụng cùng đọc một luồng, cần đọc lại hoặc xử lý thời gian thực theo thứ tự: Kinesis. Một việc, mỗi tin một consumer: SQS.
- Tin SQS tối đa 1 MiB; lớn hơn thì để payload ở S3 và gửi tham chiếu (extended client library).Đề cũ ghi 256 KB; giới hạn hiện tại của SQS là 1 MiB.
Sơ đồ
Tách rời bằng SQS: hàng đợi hấp thụ đột biến tải
Từng bước
- Web ghi đơn vào SQS rồi trả lời khách ngay, không chờ xử lý.
- Worker kéo tin, xử lý, ghi kết quả rồi xoá tin khỏi hàng đợi.
- Số tin tồn tăng: alarm kích hoạt scaling policy thêm worker; tin ít thì bớt.
Vòng đời một tin SQS: visibility timeout và dead-letter queue
SNS fan-out tới nhiều SQS queue
Từng bước
- Dịch vụ đơn hàng publish một lần tới SNS topic.
- SNS đẩy bản sao tin vào từng queue; queue email chỉ nhận tin khớp filter policy.
- Mỗi hệ thống xử lý độc lập; hệ thống tạm chết thì tin vẫn nằm trong queue của nó.
EventBridge: sự kiện từ AWS, SaaS và ứng dụng tới các target
Từng bước
- Dịch vụ AWS, đối tác SaaS và ứng dụng của bạn gửi sự kiện vào bus.
- Luật khớp sự kiện EC2 stopped, gửi tới Lambda và SNS.
- Luật khớp order.created, khởi động quy trình Step Functions.
- Archive giữ sự kiện để replay khi cần xử lý lại.
Step Functions điều phối quy trình đơn hàng
Từng bước
- API Gateway khởi động quy trình; từng bước chạy tuần tự, lỗi tạm thời thì Retry.
- Thanh toán xong: gửi yêu cầu duyệt và chờ (có thể vài ngày) tới khi nhận task token, rồi ghi kết quả.
- Thanh toán lỗi hẳn: Catch chuyển sang bước hoàn tác.
API Gateway trước Lambda, có throttling theo khách và đệm bằng SQS
Từng bước
- Mỗi khách gắn API key vào usage plan riêng (rate, burst, quota); vượt thì nhận 429.
- Đọc đơn: Lambda xử lý đồng bộ (integration timeout mặc định tối đa 29 giây).
- Ghi sự kiện khối lượng lớn: API Gateway đẩy thẳng vào SQS, worker xử lý sau.
SQS FIFO: thứ tự theo message group, song song giữa các group
Từng bước
- Producer gửi kèm MessageGroupId (mã tài khoản) và deduplication ID; tin trùng trong 5 phút bị bỏ.
- Mỗi group giao từng tin theo thứ tự; hai group chạy song song trên hai consumer.
Kinesis Data Streams: nhiều consumer cùng đọc một luồng
Từng bước
- Bản ghi cùng partition key vào cùng shard, giữ thứ tự trong shard.
- Ba ứng dụng cùng đọc toàn bộ luồng, mỗi bên giữ vị trí đọc riêng; Firehose ghi xuống S3.
Amazon MQ: chuyển ứng dụng JMS lên AWS không sửa code
Từng bước
- Ứng dụng chuyển lên EC2, vẫn nói JMS / OpenWire với broker.
- Active/standby ở hai AZ dùng chung lưu trữ; active hỏng thì standby lên thay.
So sánh nhanh
SQS, SNS, EventBridge, Kinesis Data Streams
| SQS | SNS | EventBridge | Kinesis Data Streams | |
|---|---|---|---|---|
| Mô hình | Hàng đợi, consumer kéo | Pub/sub, đẩy tới subscriber | Bus sự kiện, luật lọc theo nội dung | Luồng có shard, consumer đọc theo vị trí |
| Một tin tới | Một consumer | Mọi subscriber | Mọi target của các luật khớp | Mọi consumer (mỗi bên tự đọc) |
| Giữ tin | Mặc định 4 ngày, tối đa 14 ngày | Không giữ (giao ngay, có retry) | Không giữ; có archive để replay | Theo thời gian lưu giữ của stream |
| Thứ tự | FIFO: trong message group | FIFO topic: trong message group | Không đảm bảo | Trong mỗi shard |
| Hợp với | Đệm tải, tách rời worker | Fan-out, thông báo | Phản ứng sự kiện AWS / SaaS, định tuyến | Log, clickstream, IoT, phân tích thời gian thực |
SQS Standard và FIFO
| Standard | FIFO | |
|---|---|---|
| Thứ tự | Cố gắng, không đảm bảo | Đúng thứ tự trong mỗi message group |
| Giao tin | Ít nhất một lần (có thể trùng) | Đúng một lần (dedup trong 5 phút) |
| Thông lượng | Gần như không giới hạn | 300 TPS mỗi API (3.000 tin/giây khi batch 10); high throughput mode cao hơn nhiều |
| Tên queue | Tuỳ ý | Phải kết thúc bằng .fifo |
| Dùng khi | Mặc định cho phần lớn workload | Giao dịch ngân hàng, đơn hàng, lệnh phải theo thứ tự |
Step Functions Standard và Express
| Standard | Express | |
|---|---|---|
| Thời gian tối đa | 1 năm | 5 phút |
| Ngữ nghĩa | Đúng một lần | Async: ít nhất một lần; Sync: nhiều nhất một lần |
| Tính tiền | Theo số state transition | Theo số lần chạy, thời gian, bộ nhớ |
| Hợp với | Quy trình dài, có người duyệt, thanh toán | IoT, xử lý luồng, backend khối lượng lớn |
Amazon MQ và SQS / SNS
| Amazon MQ | SQS / SNS | |
|---|---|---|
| Giao thức | JMS, AMQP, MQTT, STOMP, OpenWire | API AWS (HTTPS) |
| Vận hành | Broker chạy trên máy (bạn chọn cỡ), Multi-AZ active/standby | Serverless, tự co giãn |
| Dùng khi | Chuyển app đang dùng ActiveMQ / RabbitMQ, không muốn sửa code | Ứng dụng mới trên AWS |
Tình huống đề hay gặp
1Web app nhận đơn hàng; lúc khuyến mãi lượng đơn tăng 20 lần, tầng xử lý không kịp và làm rơi đơn. Cần không mất đơn, chi phí hợp lý.
Xem đáp án
Đúng: Đặt SQS giữa web và tầng xử lý; worker trong Auto Scaling group co giãn theo số tin tồn (ApproximateNumberOfMessagesVisible / số tin trên mỗi máy)
Hàng đợi hấp thụ đột biến, worker xử lý dần, không mất đơn.
Sai: Tăng cỡ EC2 của tầng xử lý lên thật lớn
Tốn tiền lúc bình thường, vẫn có ngưỡng; không giải quyết việc web và xử lý dính chặt vào nhau.
Sai: SNS topic giữa web và tầng xử lý
SNS không giữ tin; consumer quá tải thì tin vẫn phải giao ngay.
2Một tin lỗi định dạng làm consumer hỏng, tin quay lại hàng đợi và bị xử lý lại hàng trăm lần.
Xem đáp án
Đúng: Cấu hình dead-letter queue với maxReceiveCount (ví dụ 5)
Sau 5 lần nhận vẫn không xoá được, tin chuyển sang DLQ để điều tra, không chặn các tin khác.
Sai: Giảm visibility timeout
Tin chỉ quay lại nhanh hơn, vẫn lỗi mãi.
3Consumer mất khoảng 2 phút cho mỗi tin; nhiều tin bị xử lý hai lần.
Xem đáp án
Đúng: Tăng visibility timeout lớn hơn thời gian xử lý (hoặc gọi ChangeMessageVisibility khi đang xử lý)
Visibility timeout mặc định 30 giây: tin hiện lại cho consumer khác trước khi xử lý xong.
Sai: Chuyển sang FIFO queue
FIFO chống trùng ở phía gửi (dedup), không ngăn tin hiện lại khi xử lý quá visibility timeout.
4Khi có đơn hàng mới, ba hệ thống (kho, hoá đơn, email) đều cần nhận và xử lý độc lập; hệ thống nào tạm chết cũng không được mất tin.
Xem đáp án
Đúng: SNS topic fan-out tới ba SQS queue, mỗi hệ thống đọc queue của mình
Mỗi queue giữ tin tới 14 ngày; có thể dùng filter policy để mỗi queue chỉ nhận loại tin cần.
Sai: Một SQS queue cho cả ba hệ thống cùng đọc
Mỗi tin chỉ tới một consumer; ba hệ thống sẽ chia nhau tin.
Sai: SNS gửi thẳng HTTP tới ba hệ thống
Hệ thống chết lâu thì hết retry, mất tin.
5Cần chạy một Lambda mỗi khi một EC2 instance trong tài khoản chuyển sang trạng thái stopped.
Xem đáp án
Đúng: Luật EventBridge khớp sự kiện "EC2 Instance State-change Notification" với state = stopped, target là Lambda
Dịch vụ AWS tự gửi sự kiện vào default event bus; luật lọc theo nội dung.
Sai: Lambda chạy mỗi phút gọi DescribeInstances
Polling tốn và chậm.
Sai: CloudTrail gửi thẳng tới Lambda
CloudTrail ghi log API, không phải cơ chế định tuyến sự kiện.
6Quy trình xử lý đơn gồm kiểm tra kho, trừ tiền, giao hàng, có bước chờ người duyệt tới vài ngày; mỗi bước lỗi phải retry hoặc hoàn tác.
Xem đáp án
Đúng: Step Functions Standard (Retry, Catch, callback .waitForTaskToken cho bước duyệt)
Chạy tới 1 năm, đúng một lần, xem được từng bước trong lịch sử thực thi.
Sai: Một Lambda gọi lần lượt các Lambda khác
Lambda tối đa 15 phút, không chờ được nhiều ngày, tự viết retry / hoàn tác rất phức tạp.
Sai: Step Functions Express
Tối đa 5 phút.
7Giao dịch chứng khoán của từng tài khoản phải được xử lý đúng thứ tự, không trùng; các tài khoản khác nhau được xử lý song song.
Xem đáp án
Đúng: SQS FIFO, MessageGroupId = mã tài khoản
Thứ tự giữ trong từng group; các group khác nhau xử lý song song.
Sai: SQS Standard
Không đảm bảo thứ tự, có thể giao trùng.
Sai: FIFO queue với một MessageGroupId chung cho tất cả
Đúng thứ tự nhưng chỉ xử lý tuần tự, mất song song.
8Công ty chuyển ứng dụng Java dùng JMS với ActiveMQ tại chỗ lên AWS, muốn sửa code ít nhất.
Xem đáp án
Đúng: Amazon MQ for ActiveMQ
Broker được quản lý, giữ nguyên giao thức JMS / OpenWire; bật active/standby Multi-AZ cho HA.
Sai: Viết lại phần nhắn tin bằng SQS
Phải sửa code, đổi API.
9Dữ liệu clickstream cần được ba ứng dụng (tính chỉ số thời gian thực, lưu S3, phát hiện gian lận) cùng đọc, có thể đọc lại khi lỗi.
Xem đáp án
Đúng: Kinesis Data Streams với nhiều consumer (Lambda, Firehose → S3, ứng dụng riêng)
Dữ liệu giữ trong stream theo thời gian lưu giữ, mỗi consumer đọc theo vị trí riêng.
Sai: SQS Standard
Mỗi tin chỉ một consumer, xoá xong là mất, không đọc lại được.
10API công khai trên API Gateway + Lambda bị một khách gọi quá nhiều làm ảnh hưởng khách khác.
Xem đáp án
Đúng: Usage plan + API key với throttling và quota riêng cho từng khách (REST API)
Giới hạn theo khách ở cửa API, khách vượt nhận 429.
Sai: Tăng reserved concurrency của Lambda
Chỉ cho khách xấu dùng nhiều hơn.
Chọn nhanh
Cần nối các thành phần thế nào?
| Khi cần | Dùng |
|---|---|
| Đệm đột biến tải giữa hai tầng, mỗi việc một worker xử lý | SQS Standard + Auto Scaling theo số tin · xem sơ đồ |
| Xử lý đúng thứ tự, không trùng | SQS FIFO (MessageGroupId) · xem sơ đồ |
| Tin lỗi lặp lại mãi | Dead-letter queue + maxReceiveCount · xem sơ đồ |
| Một tin tới nhiều hệ thống, không mất khi hệ thống tạm chết | SNS fan-out → nhiều SQS · xem sơ đồ |
| Phản ứng sự kiện dịch vụ AWS hoặc SaaS, lọc theo nội dung | EventBridge (rule + target) · xem sơ đồ |
| Chạy theo lịch (cron) | EventBridge Scheduler |
| Quy trình nhiều bước, retry, chờ duyệt | Step Functions Standard · xem sơ đồ |
| Khối lượng lớn, mỗi lần chạy ngắn (dưới 5 phút) | Step Functions Express |
| Cửa HTTP cho Lambda / backend, throttling theo khách | API Gateway (usage plan) · xem sơ đồ |
| Nhiều consumer cùng đọc luồng, đọc lại được | Kinesis Data Streams · xem sơ đồ |
| App đang dùng JMS / AMQP / MQTT | Amazon MQ · xem sơ đồ |
| GraphQL, đồng bộ dữ liệu thời gian thực cho app di động | AWS AppSync |
Bẫy hay gặp
- Dùng một SQS queue cho nhiều hệ thống cần cùng nhận tin: SQS chia tin, không broadcast.
- Xử lý lâu hơn visibility timeout nên tin bị xử lý hai lần.
- Quên xoá tin sau khi xử lý xong: tin quay lại hàng đợi.
- Tin lỗi lặp vô hạn vì không cấu hình dead-letter queue.
- Chọn FIFO cho workload cần thông lượng cực lớn mà không cần thứ tự.
- Dùng một MessageGroupId cho mọi tin FIFO rồi thắc mắc vì sao không chạy song song.
- Dùng SNS (không giữ tin) khi đề yêu cầu đệm tải hoặc không mất tin lúc consumer chết.
- Dùng CloudTrail hay polling để "bắt sự kiện" thay vì luật EventBridge.
- Lambda gọi chuỗi Lambda cho quy trình dài thay vì Step Functions.
- Chọn Step Functions Express cho quy trình chạy lâu hơn 5 phút.
- Viết lại ứng dụng JMS sang SQS khi đề yêu cầu sửa code ít nhất (đó là Amazon MQ).
- Nhớ giới hạn tin SQS là 256 KB: hiện là 1 MiB.
Dịch vụ trong module
SQShàng đợi tin nhắn
SNSphát thông báo (pub/sub)
EventBridgeđịnh tuyến sự kiện- Pipesnối nguồn sự kiện tới đích
- Schedulerlập lịch gọi tác vụ
Step Functionsđiều phối quy trình
API Gatewaycổng vào cho API
MQmessage broker ActiveMQ/RabbitMQ
AppSyncGraphQL API được quản lý
Kinesis Data Streamsluồng dữ liệu real-time
Lambdachạy code theo sự kiện
Số liệu dễ thay đổi (đã kiểm với tài liệu AWS)
- SQS: tin tối đa 1 MiB; giữ tin mặc định 4 ngày (1 phút tới 14 ngày); visibility timeout mặc định 30 giây, tối đa 12 giờ; delay tối đa 15 phút. kiểm ngày 2026-10-16 ↗
- SQS FIFO: 300 giao dịch/giây mỗi API (3.000 tin/giây khi batch 10); long polling tối đa 20 giây; tối đa 120.000 tin in-flight. kiểm ngày 2026-10-16 ↗
- SNS: topic mặc định nhận tin tới 256 KiB, cấu hình được tới 1 MiB (chỉ với subscriber SQS, Lambda, Firehose). kiểm ngày 2026-10-16 ↗
- Step Functions: Standard tối đa 1 năm, đúng một lần, tính theo state transition; Express tối đa 5 phút, tính theo số lần chạy, thời gian, bộ nhớ. kiểm ngày 2026-10-16 ↗
- EventBridge (classic): tối đa 5 target mỗi luật. kiểm ngày 2026-10-16 ↗
- API Gateway: mặc định 10.000 request/giây mỗi tài khoản mỗi Region (burst 5.000). kiểm ngày 2026-10-16 ↗
- API Gateway REST: integration timeout 50 ms – 29 giây, tăng được với API Regional / private; payload tối đa 10 MB. kiểm ngày 2026-10-16 ↗
- Lambda + SQS: Lambda kéo tin theo batch, xử lý ít nhất một lần; dùng partial batch response để không xử lý lại tin đã thành công. kiểm ngày 2026-10-16 ↗