skip to content

In Amazon SQS, what are the differences between a standard queue and a FIFO queue, and when would you choose each?

level: juniorimportance: must knowfreq 80%

answer

  1. throughput versus ordering
  2. duplicates are normal on one side
  3. order holds only inside a group
  4. queue name must end .fifo
  5. chosen at creation, never converted

basics

~20 s

Standard SQS queues give near-unlimited throughput with best-effort ordering and possible duplicate deliveries. FIFO queues preserve order within each MessageGroupId and deduplicate messages, but cap throughput. Choose FIFO only when ordering or deduplication is genuinely required.

solid answer

~40 s

SQS has exactly two queue types, fixed at creation. A **standard** queue is optimised for throughput: AWS publishes no inbound message-rate quota, delivery is at-least-once, and ordering is best effort, so a consumer can legitimately see the same message twice or see messages out of send order. A **FIFO** queue trades that away: its name must end in `.fifo`, every `SendMessage` carries a `MessageGroupId`, and SQS delivers messages in order within each group and suppresses duplicate sends that share a `MessageDeduplicationId` inside a five-minute window. The price is a much lower default throughput quota, higher per-request pricing, and head-of-line blocking inside a group. So I default to standard plus idempotent consumers, and reach for FIFO only when later messages are meaningless unless earlier ones were applied first.

code

bash · 4 lines
bash
aws sqs create-queue --queue-name orders.fifo \
  --attributes FifoQueue=true,ContentBasedDeduplication=true

aws sqs create-queue --queue-name thumbnails

go deeper

for a junior

Be ready to name the two queue types and state plainly that standard means high throughput with possible duplicates and out-of-order delivery, while FIFO means ordering within a group at lower throughput.

for a middle

Explain why standard queues duplicate and reorder — redundant distributed storage and independent receives — and describe what a FIFO queue requires on every send, namely a message group id and a deduplication id.

for a senior

Show the operational cost of picking FIFO: the throughput quota, higher per-request price, and one stuck message blocking its whole group. Say when you would keep a standard queue and absorb duplicates with idempotent handlers.

for a principal

Own the position that ordering is a constraint you pay for, not a feature you enable. Discuss keeping order requirements at the narrowest entity scope so most traffic stays on cheap unordered paths, and the migration cost of getting the choice wrong.

## Two queue types, chosen once SQS offers a standard queue and a FIFO queue. The choice is made at `CreateQueue` and cannot be changed afterwards — there is no attribute that converts one into the other. A FIFO queue is created by passing the `FifoQueue` attribute as `true`, and its name **must** end with the literal suffix `.fifo`; a create call that sets the attribute on a name without that suffix is rejected. ## What a standard queue actually guarantees A standard queue guarantees two things: a message that is successfully sent will be delivered **at least once**, and delivery order is **best effort**. It deliberately does not guarantee that a message is delivered only once, nor that messages arrive in the order they were sent. Both caveats come from the same implementation choice. A standard queue stores each message redundantly across many servers, and receives are served independently from those copies. If a `DeleteMessage` does not register on every copy — for example because a host was unreachable for a moment — a surviving copy becomes visible again and the consumer sees the message a second time. Likewise, because two receives can land on different servers holding different subsets of the backlog, the sequence a consumer observes is only approximately the send sequence. In exchange, AWS publishes no maximum inbound rate for a standard queue: you send as fast as your producers can, and you scale consumers horizontally without any coordination between them. ## What a FIFO queue adds A FIFO queue adds two guarantees, both scoped narrowly: - **Ordering per message group.** Every send must supply a `MessageGroupId`. Messages that share a group are delivered in the order they were accepted; messages in different groups have no ordering relationship and are processed in parallel. There is no such thing as queue-wide ordering unless you put everything into one group — which serialises the whole queue. - **Deduplication inside a window.** Every send must supply a `MessageDeduplicationId`, or the queue must have `ContentBasedDeduplication` enabled so SQS derives one from a SHA-256 hash of the body. A second send with the same id inside a five-minute interval is accepted by the API but never delivered. AWS markets this as "exactly-once processing", and it is worth being precise about what that means: SQS will not *deliver* a duplicate of an already-accepted deduplication id within the window, and it will not deliver the next message of a group until the previous one is deleted or becomes visible again. It does not mean your handler runs exactly once end to end. ## The price of ordering Three costs show up in real systems. First, **throughput**. A FIFO queue in the default mode is quota-limited per API action (300 calls per second per action, which becomes about 3,000 messages per second when you batch ten per call), whereas a standard queue has no comparable ceiling. High throughput mode raises this substantially but changes deduplication scope. Second, **head-of-line blocking**. If one message in a group cannot be processed, everything behind it in that group waits. On a standard queue a poison message only occupies one consumer; on a FIFO queue it stalls a whole ordered stream. Third, **price**. FIFO API requests are billed at a higher rate per million than standard requests, which matters at volume. ## Choosing between them Ask what breaks without ordering. If applying message B before message A produces a wrong end state — balance updates for one account, state-machine transitions for one order, a create-then-update pair for one record — that is FIFO's case, with the entity id as the group key. If the messages are mutually independent units of work — resize this image, send this email, index this document — a standard queue plus a consumer that tolerates seeing a message twice is faster, cheaper, and simpler to scale. ```bash aws sqs create-queue --queue-name orders.fifo \ --attributes FifoQueue=true,ContentBasedDeduplication=true ``` The common trap is treating FIFO as a general upgrade. It is a narrowing: it buys per-group order and a short dedup window, and it charges for that in throughput, blast radius of a single bad message, and cost.

  • Can you switch an existing standard queue to FIFO once it is in production?
    No. The queue type is set at creation and there is no attribute that changes it, and a FIFO queue needs a name ending in `.fifo`, so the URL changes too. You create a new FIFO queue, point producers at it, drain the old queue with the existing consumers, then retire it. Plan for a window where both are live.
  • If a standard queue is at-least-once, how do you stop duplicate work?
    You make the consumer idempotent rather than trying to make delivery unique: key the side effect on something stable in the message, such as an order id, and make a repeat apply the same end state instead of a second one. That is cheaper than FIFO and it also covers redelivery after a consumer crash, which no queue type prevents.
  • Does a FIFO queue guarantee that messages come out in the exact order they were sent, queue-wide?
    No. The guarantee is per `MessageGroupId`. Two messages in different groups have no defined relative order and are typically handled concurrently by different consumers. Queue-wide ordering only exists if every message shares one group id, which serialises the queue and throws away consumer parallelism.

saying these in an interview costs you the question

  • Says FIFO queues order the entire queue globally
  • Claims standard queues are ordered in practice most of the time
  • Believes you can convert a standard queue to FIFO in place
  • Treats FIFO as strictly better and defaults to it
  • Thinks duplicates on a standard queue mean a bug in SQS

context

resolving links…