Idempotency & at-least-once processing

Core details

At-least-once delivery: duplicates happen—handlers must converge.

Idempotency key pattern: deterministic business key + store outcome; replays short-circuit identical effects.

Transactional outbox: write business row + outbox event in one DB transaction → relay publishes reliably without “dual write” fantasy.

Inbox / dedupe table on consumer side for broker redeliveries.

Sagas / process managers: multi-step workflows with explicit compensations—not “distributed transactions” denial realism honest.

Understanding

Retries—including client, gateway, and broker—multiply attempts. Without idempotent effects you get double charges, duplicate tickets, fan-out storms. “Exactly-once” rhetoric in interviews should be reframed honestly: effective-once via dedupe + deterministic side-effect design.

Ordering: single partition per entity often trades throughput for simpler reasoning—state when you’d relax ordering.

Senior understanding

Webhook story: verify signature before acknowledging; persist idempotency outcome before returning 2xx; classify transient vs permanent downstream errors to avoid infinite poison replays without DLQ observability.

Discuss clock skew minimally only if relevant—focus on key design + transactional boundaries first.

Diagram

See also

• Caching & consistency
• /backend