Exactly-once Semantics
FIFO + deduplication + idempotent consumers = effectively exactly-once.
True exactly-once in distributed systems is impossible; SQS gets as close as is practically useful by combining producer-side dedup with FIFO delivery.
What AWS provides
Unlike standard queues, FIFO queues don't introduce duplicate messages on the producer side. If you retry SendMessage within the 5-minute deduplication interval, SQS does not enqueue a second copy. This is exactly-once delivery to the queue, not end-to-end exactly-once processing.
Producer side
Send with a stable MessageDeduplicationId derived from the business event (invoice ID, webhook delivery ID). Enable content-based deduplication only when the body is truly identical across retries.
- Explicit dedup ID: full control, recommended for most apps.
- Content-based dedup: convenient but fragile if body varies slightly.
Consumer side
Even with FIFO, messages can be re-delivered if processing exceeds the visibility timeout or the worker crashes before DeleteMessage. Consumers must still implement idempotency.
End-to-end model
Effective exactly-once = FIFO producer deduplication + visibility timeout aligned with processing time + idempotent consumer + DLQ for poison messages. Missing any layer returns you to at-least-once semantics in practice.
- !Exactly-once is end-to-end only with producer dedup AND consumer idempotency. Skip either and you're back to at-least-once.
- !Visibility timeout expiry causes re-delivery — deduplication does not prevent re-processing.