Idempotency in Three Layers

A transaction crosses three independent dedup boundaries — ingest, worker, and emit — so a retry at any stage still produces exactly one effect

Idempotency in Three Layers A transaction crosses three independent dedup boundaries — ingest, worker, and emit — so a retry at any stage still produces exactly one effect 01 / Client 02 / Ingest 03 / Worker 04 / Emit 05 / Effect Client · at-least-once send · 01 / Client Client at-least-once send Retry · duplicate delivery · 01 / Client · same key Retry duplicate delivery same key Ingest Dedup · request key · 02 / Ingest · layer 1 Ingest Dedup request key layer 1 Worker Dedup · processing token · 03 / Worker · layer 2 Worker Dedup processing token layer 2 Emit Dedup · outbox key · 04 / Emit · layer 3 Emit Dedup outbox key layer 3 Ledger · exactly one entry · 05 / Effect · once Ledger exactly one entry once transaction duplicate deduped once processed once committed once Legend primary data policy / PII async batch data store

Three Independent Guards

  • • Ingest keys the raw request at the boundary
  • • Worker keys the unit of processing it performs
  • • Emit keys the downstream effect via an outbox

Retry Safety

  • • A retry at any stage hits its own dedup check
  • • Each layer collapses duplicates on its own key
  • • No single layer is trusted to catch everything

Exactly One Effect

  • • The ledger records exactly one entry per transaction
  • • Duplicate sends never double-charge or double-post
  • • Independence means one failed guard is not fatal

Data-flow diagram • Built with Archify • Create yours ↗ • Hover to trace • R route • Click to focus • +/− zoom • M radar • [/] views • P play story • T theme • E export