Moving from a standard queue to a FIFO queue in Amazon SQS - Amazon Simple Queue Service

Moving from a standard queue to a FIFO queue in Amazon SQS

If you have an existing application that uses standard queues and you want to take advantage of the ordering or exactly-once processing features of FIFO queues, you need to configure the queue and your application correctly.

Note

You can't convert an existing standard queue into a FIFO queue. To make the move, you must either create a new FIFO queue for your application or delete your existing standard queue and recreate it as a FIFO queue.

To make sure that your application correctly works with a FIFO queue, use the following checklist:

  • Use the recommended high throughput mode for FIFO to achieve increased throughput. To learn more about messaging quotas, see Amazon SQS message quotas.

  • FIFO queues don't support per-message delays, only per-queue delays. If your application sets the same value of the DelaySeconds parameter on each message, you must modify your application to remove the per-message delay and set DelaySeconds on the entire queue instead.

  • Message group is a unique FIFO feature that enables customers to process messages in parallel while maintaining their respective ordering. Customers organize messages into message groups by specifying a message group ID. Message groups are often based on a business dimension for a given workload. To better scale with FIFO queues, use a more granular business dimension for message ID. The more message group IDs you distribute messages to, the greater number of messages FIFO makes available for consumption.

  • Before sending messages to a FIFO queue, confirm the following:

    • If your application can send messages with identical message bodies, you can modify your application to provide a unique message deduplication ID for each sent message.

    • If your application sends messages with unique message bodies, you can enable content-based deduplication.

  • You don't have to make any code changes to your consumer. However, if it takes a long time to process messages and your visibility timeout is set to a high value, consider adding a receive request attempt ID to each ReceiveMessage action. This allows you to retry receive attempts in case of networking failures and prevents queues from pausing due to failed receive attempts.

For more information, see the Amazon Simple Queue Service API Reference.