What does an Amazon SNS FIFO topic give you that a standard topic does not, and what does it require from publishers and subscribers?

## What the two topic types actually promise A **standard** SNS topic is optimised for throughput: very high publish rates, at-least-once delivery, and no ordering guarantee — two subscribers may legitimately observe the same two events in different orders. A **FIFO** topic adds two guarantees at a substantial throughput cost: 1. **Ordering within a message group.** Messages published with the same `MessageGroupId` are delivered to a subscriber in the order they were accepted. Different groups are independent and may be interleaved arbitrarily — that independence is exactly what allows any parallelism at all. 2. **Deduplication.** Within a deduplication interval (five minutes, as of 2025), a second publish with the same deduplication identity is accepted and acknowledged but not delivered. This protects against a retrying publisher creating a duplicate, not against a consumer processing the same message twice. ## What publishers must do - The topic is created with the `FifoTopic` attribute set to true and a name ending in `.fifo`. This is **immutable** — you cannot convert a standard topic to FIFO or back; you create a new topic and migrate. - Every `Publish` supplies a `MessageGroupId`. Choosing it is the real design decision: it is your ordering key and your parallelism key at the same time. `orderId` or `customerId` is usually right; a constant value serialises the entire topic and destroys throughput; something too fine-grained silently gives up the ordering you wanted. - Every `Publish` supplies a `MessageDeduplicationId`, unless the topic has `ContentBasedDeduplication` enabled, in which case SNS derives one from the message body. Content-based deduplication is a trap for legitimately identical payloads — two genuine "heartbeat ok" events a minute apart are the same body, and the second one disappears. ## What subscribers must do FIFO topics exist to fan out into queues. Ordering survives to the consumer only when the subscribed queue is an **SQS FIFO queue**, which carries the group ordering through to delivery: SQS will not hand out a second message from a group while an earlier one from that group is still in flight. Subscribe a standard queue instead and you keep the fanout and the publish-side deduplication, but the queue reorders freely — a perfectly reasonable choice for a subscriber that does not care about sequence and wants the higher throughput. Two consequences follow that candidates often miss: - **A stuck message blocks its group.** With FIFO, a poison message in group `order-42` halts that group until it is deleted or dead-lettered. That is the price of ordering, and it is why a dead-letter queue and a sensible `maxReceiveCount` matter more, not less, under FIFO. - **Consumer concurrency must respect groups.** Ordering is only preserved if a single consumer handles a group at a time, which SQS FIFO enforces by not releasing the group. Your worker pool scales across groups, never within one. ## The throughput conversation FIFO topics and FIFO queues have far lower throughput quotas than their standard counterparts, and those quotas are per topic and per queue. If your event rate is high, the honest answer is usually not "raise the quota" but "do you actually need global ordering, or do you need per-entity ordering?" Per-entity ordering with a well-chosen group id is achievable; a single ordered stream for an entire domain is a scaling dead end. A frequently better alternative is to keep the topic standard and make ordering a consumer concern: attach a monotonically increasing version or sequence number to each event and let the consumer discard anything older than what it has already applied. That gives you idempotent, order-tolerant processing at standard-topic throughput, and it is what most large systems actually do. Reach for FIFO when the ordering requirement is genuinely a business invariant — a financial ledger, a state machine that cannot go backwards — and when the volume fits inside the quota comfortably. ## Saying it in an interview "FIFO gives me ordering per message group and a short deduplication window, at the cost of throughput and of head-of-line blocking inside a group. It needs a group id on every publish, a deduplication id or content-based deduplication, and FIFO queues on the other side or the ordering evaporates. I'd pick the group id to match the entity whose ordering matters, and I'd check first whether a sequence number on a standard topic solves it more cheaply."