A team asks to convert a high-volume standard SQS queue to FIFO because production shows duplicate and out-of-order messages. How do you evaluate that request?

## Split the request into two questions The request bundles two very different complaints, and conflating them is the mistake to catch. **"We see duplicates."** A standard queue guarantees at-least-once delivery; duplicates are the contract, not a fault. More importantly, FIFO does not eliminate them. Its deduplication protects the *send* path within a five-minute window; it does nothing when a consumer processes a message and dies before deleting it, which is the duplicate that actually corrupts state. So a team that moves to FIFO for this reason pays the full cost and still needs idempotent handlers. This complaint is answered by making the effect converge on a repeat, keyed on a business identifier — and once that exists, the duplicates stop mattering. **"We see reordering."** This is the only symptom FIFO genuinely addresses. The question to ask is narrow and concrete: which pairs of messages, if applied in the wrong order, leave the system in a wrong end state? Very often the honest answer is "only events for the same account" or "only create-then-update for the same record", and sometimes it is "none — the handler is order-insensitive and someone just found the log confusing". ## Consider the cheaper designs first Before the queue type changes, three alternatives usually deserve a hearing. *Idempotency plus tolerance.* If handlers are order-insensitive and convergent, neither symptom is a defect. *Version or sequence numbers.* Producers stamp a monotonically increasing version per entity, and the consumer discards anything older than what it has already applied. This gives correct end state under reordering on a standard queue, with no throughput ceiling. It is the pattern to reach for when the domain is last-write-wins. *Split the stream.* Route only order-sensitive events to a FIFO queue keyed on the entity, and keep the high-volume remainder on the standard queue. This is frequently the best outcome: the ordering constraint applies to the traffic that needs it, and the bulk volume never touches the FIFO quota. ## If FIFO is the right answer, scope it honestly Four costs should be on the table before anyone agrees. **It is a migration, not a setting.** Queue type is fixed at creation and a FIFO queue's name must end in `.fifo`, so the queue URL changes. The realistic plan: create the FIFO queue, deploy consumers that read both, switch producers, drain the old queue, then delete it. Note that during the switch, in-flight messages exist in two queues with no ordering between them — for a genuinely order-sensitive stream that may require a brief producer pause rather than a rolling cutover. **Throughput.** A default FIFO queue is quota-limited per API action, unlike the standard queue the team is currently enjoying. "High volume" in the request is a warning sign; you need the current peak rate before agreeing, and you need to know whether high throughput mode plus batching covers it. **Blast radius.** With ordering comes head-of-line blocking: a message that cannot be processed halts every later message in its group. On the standard queue a poison message ties up one consumer; afterwards it freezes a customer's entire stream. The group key decides how much is frozen, so the key must be as narrow as correctness allows. **Feature and cost differences.** FIFO requests are priced higher per million. FIFO queues also do not support per-message delay values — you can set a delay on the queue, but not on an individual send — which occasionally breaks an existing scheduling trick. ## The group key is the real design decision If the migration proceeds, the durable decision is not "FIFO" but the group key, because it is embedded in producer code and re-keying later means another drain window. Choose the narrowest identity for which ordering is required — the entity being mutated — so the queue behaves as thousands of small ordered lanes rather than one pipe. ## How to answer in an interview State the position: ordering is a constraint you buy, and its price is throughput, blast radius and migration cost. Show that you separate the duplicate complaint from the ordering complaint, that idempotency is required either way, and that you would look for the smallest slice of traffic that truly needs order before converting the whole queue.