So sánh delivery guarantee và các tham số cấu hình dễ nhầm lẫn
Các dịch vụ messaging khác nhau ở delivery guarantee (at-least-once, exactly-once) và ở các tham số cấu hình; chọn sai dễ dẫn tới mất dữ liệu hoặc tốn chi phí không cần thiết.
Ba tình huống của MFTECH: biểu mẫu đăng ký người bán phải được xử lý đúng một lần, không mất dữ liệu ở tầng xử lý phía sau; chi phí SQS cao do worker nhận về quá nhiều phản hồi rỗng; luồng dữ liệu theo thời gian thực từ thiết bị quét mã tại kho cần một kênh tiếp nhận có thể co giãn và cho phép xử lý lại khi tầng phân tích gặp lỗi. Chọn từng mục để xem phạm vi sử dụng và phương án phù hợp.
Định tuyến sự kiện từ ứng dụng, dịch vụ AWS hoặc SaaS tới nhiều target bằng rule. Giao không thành công: mặc định retry trong 24 giờ, tối đa 185 lần, với exponential backoff; hết số lần retry thì sự kiện bị bỏ, trừ khi cấu hình dead-letter queue.
Vì sao không chọn trong tình huống nàyBiểu mẫu đăng ký người bán phải được xử lý đúng một lần. EventBridge phân phối at-least-once: cùng một target có thể được gọi nhiều lần cho một sự kiện, thứ tự không được đảm bảo, và sự kiện không được lưu lại để tầng xử lý tự lấy theo tốc độ của mình. Enhanced custom event bus (9/2026) có phân phối theo thứ tự và content-based deduplication, nhưng vẫn là bus định tuyến sự kiện, không phải hàng đợi đệm giữa hai tầng.
Phương án phù hợpSQS FIFO queue giữa web tier và tầng xử lý: deduplication trong khoảng 5 phút, đúng thứ tự trong từng message group, message được lưu tới khi worker xử lý xong và xoá (Phần 3).
Kênh tiếp nhận luồng dữ liệu bằng Kinesis Data Streams và cách nhiều ứng dụng cùng đọc một stream được trình bày trong bài Kinesis, Phần 1.
- Xử lý đúng một lần giữa hai tầng: SQS FIFO; standard queue và EventBridge event bus classic đều at-least-once.
- Giảm chi phí do nhận rỗng: long polling, không phải message timer hay visibility timeout.
- SNS có retry và DLQ, nhưng standard topic không lưu message để đọc lại; luồng dữ liệu cần lưu giữ và xử lý lại: Kinesis Data Streams.
Comparing delivery guarantees and easily confused configuration settings
Messaging services differ in delivery guarantees (at-least-once, exactly-once) and configuration settings; a wrong choice easily leads to lost data or unnecessary cost.
Three MFTECH situations: seller registration forms must be processed exactly once, with no data loss by the back-end processing tier; SQS costs are high because workers receive too many empty responses; a real-time data stream from the warehouse barcode scanners needs a scalable ingestion channel that allows reprocessing when the analytics tier fails. Choose each item to see what it is for and what fits instead.
Routes events from applications, AWS services or SaaS to multiple targets through rules. On failed delivery it retries by default for 24 hours and up to 185 times with exponential backoff; once retries are exhausted the event is dropped unless a dead-letter queue is configured.
Vì sao không chọn trong tình huống nàySeller registration forms must be processed exactly once. EventBridge delivers at least once: the same target can be invoked more than once for one event, ordering is not guaranteed, and events are not kept for the processing tier to pull at its own pace. The enhanced custom event bus (September 2026) offers ordered delivery and content-based deduplication, but it is still an event router, not a buffer queue between two tiers.
Phương án phù hợpAn SQS FIFO queue between the web tier and the processing tier: deduplication within a 5-minute interval, ordering within each message group, and messages kept until a worker processes and deletes them (Part 3).
Ingesting a data stream with Kinesis Data Streams and letting several applications read the same stream are covered in the Kinesis lesson, Part 1.
- Exactly-once processing between two tiers: SQS FIFO; standard queues and the classic EventBridge event bus are both at-least-once.
- Lower cost from empty receives: long polling, not message timers or the visibility timeout.
- SNS has retries and DLQs, but a standard topic does not keep messages for re-reading; a data stream that must be retained and reprocessed: Kinesis Data Streams.