Back to roadmap
Module 8 · Caching, Queues, Async WorkDay 07725 min

Exactly-once vs At-least-once

Pick at-least-once + idempotent — the only honest answer.

Day 077

Exactly-once vs At-least-once

App
service
DB (orders + outbox)
datastore
Outbox shipper
service
Broker
queue
Signal path
Transactional outbox
App
service
flow
DB (orders + outbox)
datastore
DB (orders + outbox)
datastore
flow
Outbox shipper
service
Outbox shipper
service
flow
Broker
queue
Memory hook

Exactly-once vs At-least-once: pick at-least-once + idempotent

Mental model

absorb bursts before they become outages

Design lens

Outbox adds a process and table.

Recall anchors
At-least-once + idempotentOutbox patternKafka transactions

Why it matters

Exactly-once delivery is a marketing claim across most boundaries. The practical pattern is at-least-once delivery plus idempotent consumers, optionally framed by transactional outbox to avoid losing messages on producer crashes.

Deep dive

Network failures imply duplicates; consumers must dedupe by message_id or business key.

Outbox pattern: write business state and outbox row in same DB transaction; a separate process publishes outbox rows to broker.

Kafka transactions provide exactly-once within Kafka; cross-system, you still need idempotency.

Demo / scenario

Order created → email sent.

  1. Save order + outbox row in single Postgres tx.
  2. Outbox shipper publishes to Kafka.
  3. Email worker dedups by order_id (idempotent).
  4. On retry, no double email.

Tradeoffs

  • Outbox adds a process and table.
  • Idempotency requires storage of seen IDs.
  • Cross-system 'exactly once' is folklore.

Diagram

App
DB (orders + outbox)
Outbox shipper
Broker
Transactional outbox.

Mind map

Check yourself

Loading quiz…

Sources & further reading