Với giao dịch tài chính, thứ tự và việc xử lý đúng một lần (exactly-once processing) là bắt buộc; standard queue không bảo đảm hai yêu cầu này, do đó cần FIFO queue.

Loại queue mặc định là standard: thông lượng rất cao, nhưng một message có thể được phân phối nhiều hơn một lần và không đảm bảo thứ tự. Với đơn hàng, worker có thể tự kiểm tra trùng lặp. Với ví điện tử của MFTECH, điều này không được chấp nhận: lệnh nạp tiền phải được xử lý trước lệnh thanh toán, và mỗi lệnh chỉ được xử lý đúng một lần. Mô phỏng dưới đây so sánh ba phương án:

FIFO queue đảm bảo thứ tự và loại bỏ message trùng lặp (theo deduplication ID trong khoảng 5 phút). Đổi lại, thông lượng bị giới hạn. Khi chưa bật high throughput mode, FIFO queue hỗ trợ 300 transaction mỗi giây cho mỗi API action (SendMessage, ReceiveMessage, DeleteMessage); với batch tối đa 10 message mỗi lệnh gọi, thông lượng đạt 3.000 message mỗi giây cho mỗi API action. Điều chỉnh để kiểm tra:

Một standard queue đang vận hành không thể chuyển đổi sang FIFO queue. Cần tạo FIFO queue mới với tên kết thúc bằng .fifo, sau đó chuyển producer và consumer sang queue mới.

Đưa lệnh ví qua EventBridge cũng không đáp ứng yêu cầu. Trên event bus (loại classic), EventBridge phân phối tới target theo mô hình at-least-once: tài liệu EventBridge ghi nhận rằng trong một số trường hợp hiếm, cùng một rule có thể chạy nhiều lần cho một sự kiện, hoặc cùng một target được gọi nhiều lần; sự kiện được giao tới target theo thứ tự bất kỳ. Khi giao không thành công, EventBridge mặc định retry trong 24 giờ, tối đa 185 lần, sau đó bỏ sự kiện nếu không cấu hình dead-letter queue. EventBridge cũng không lưu sự kiện để tầng xử lý tự lấy theo tốc độ của mình như một queue. Từ 9/2026, loại enhanced custom event bus bổ sung phân phối theo thứ tự cho các sự kiện cùng EventGroupId và tuỳ chọn content-based deduplication, loại bỏ sự kiện publisher gửi lại trong vòng 5 phút; đây là tính năng của loại bus mới, không thay đổi hành vi at-least-once của event bus classic.

For financial transactions, ordering and exactly-once processing are mandatory; a standard queue does not guarantee either, so a FIFO queue is needed.

The default queue type is standard: very high throughput, but a message can be delivered more than once and ordering is not guaranteed. For orders, the worker can check for duplicates itself. For MFTECH’s e-wallet this is not acceptable: a top-up must be processed before a payment, and each command must be processed exactly once. The simulation below compares three options:

A FIFO queue guarantees ordering and removes duplicate messages (by deduplication ID within a 5-minute interval). In exchange, throughput is limited. Without high throughput mode, a FIFO queue supports 300 transactions per second per API action (SendMessage, ReceiveMessage, DeleteMessage); with batches of up to 10 messages per call, throughput reaches 3,000 messages per second per API action. Adjust the values to check:

An existing standard queue cannot be converted to a FIFO queue. You must create a new FIFO queue whose name ends in .fifo, then move the producers and consumers to the new queue.

Sending wallet commands through EventBridge does not meet the requirement either. On an event bus (the classic type), EventBridge delivers to targets at least once: the EventBridge documentation notes that in rare cases the same rule can run more than once for a single event, or the same target can be invoked more than once; events are delivered to targets in an arbitrary order. When delivery fails, EventBridge by default retries for 24 hours and up to 185 times, then drops the event unless a dead-letter queue is configured. EventBridge also does not keep events for the processing tier to pull at its own pace the way a queue does. Since September 2026, the enhanced custom event bus adds ordered delivery for events that share an EventGroupId and optional content-based deduplication that drops publisher retries within five minutes; these are features of the new bus type and do not change the at-least-once behavior of the classic event bus.