Message trong SQS queue chỉ bị xoá sau khi consumer xử lý thành công; cơ chế này bảo đảm tác vụ không bị mất khi consumer gặp sự cố trong quá trình xử lý.

Khi worker nhận một message, message chưa bị xoá khỏi queue mà chỉ bị ẩn trong một khoảng thời gian gọi là visibility timeout. Sau khi xử lý xong, worker phải gọi DeleteMessage. Nếu worker gặp sự cố trong quá trình xử lý, message hiển thị trở lại để worker khác xử lý. Các tính năng của SQS đều xoay quanh vòng đời này. Chọn từng tình huống của MFTECH và chạy mô phỏng:

Một mô hình khác: ứng dụng gửi yêu cầu tính phí vận chuyển và chờ phản hồi (request-response). Việc tạo một queue thực cho mỗi yêu cầu tốn thời gian và chi phí. Temporary queue (thông qua Temporary Queue Client) tạo các virtual queue ngay trong ứng dụng, ghép chúng lên một queue SQS thực và tự động dọn dẹp khi hoàn tất.

Delay queue áp dụng cho mọi message của queue. Khi chỉ một số message cần trì hoãn (ví dụ email nhắc thanh toán gửi sau 10 phút), producer đặt message timer: tham số DelaySeconds trên từng message khi gửi, từ 0 giây (mặc định) tới tối đa 15 phút; giá trị này ghi đè DelaySeconds của delay queue. FIFO queue không hỗ trợ timer cho từng message. Cần lập lịch xa hơn 15 phút: AWS khuyến nghị EventBridge Scheduler. Message timer, delay queue và visibility timeout chỉ quyết định khi nào message được nhìn thấy; không tính năng nào trong số này là cách nhận message, và không tính năng nào giảm số lệnh ReceiveMessage trả về rỗng. Chỉ long polling (wait time tối đa 20 giây) giảm số phản hồi rỗng và do đó giảm chi phí.

A message in an SQS queue is deleted only after the consumer has processed it successfully; this ensures no task is lost when a consumer fails during processing.

When a worker receives a message, the message is not yet deleted from the queue; it is only hidden for a period called the visibility timeout. After processing, the worker must call DeleteMessage. If the worker fails during processing, the message becomes visible again so that another worker can process it. SQS features all revolve around this life cycle. Choose each MFTECH scenario and run the simulation:

Another pattern: the application sends a request to calculate shipping fees and waits for the response (request-response). Creating a real queue for each request costs time and money. A temporary queue (through the Temporary Queue Client) creates virtual queues inside the application, multiplexes them onto one real SQS queue and cleans them up automatically when done.

A delay queue applies to every message in the queue. When only some messages need a delay (for example a payment reminder email sent after 10 minutes), the producer sets a message timer: the DelaySeconds parameter on an individual message when it is sent, from 0 seconds (the default) up to a maximum of 15 minutes; this value overrides the delay queue’s DelaySeconds. FIFO queues don’t support timers on individual messages. For scheduling further than 15 minutes ahead, AWS recommends EventBridge Scheduler. Message timers, delay queues and the visibility timeout only decide when a message is visible; none of them is a way to receive messages, and none of them reduces the number of ReceiveMessage calls that return empty. Only long polling (maximum wait time 20 seconds) reduces empty responses and therefore cost.