Idempotency model

There is no idempotency table. Tonder's entire IdempotencyTable (120s TTL) + process_id-index dedup guard + 2-day cutoff collapses to three constraints plus an atomic transaction.

The three constraints

1. transaction_events: unique(correlation_id, acquirer) — dedup at the door.
2. journals: unique(process_id, category) + ON CONFLICT DO NOTHING — dedup at posting.
3. The orchestrator transaction is atomic — a redelivery either inserts nothing or rolls back cleanly.

The 2-day cutoff

Keep Tonder's 2-day cutoff as a guard in the orchestrator: skip realtime processing of events older than 48h. Bulk reprocess bypasses it (it intentionally replays old events). See the orchestrator step 4.

Idempotency is a schema property

Because uniqueness + ON CONFLICT live in the database, correctness does not depend on queue-redelivery behavior, retry counts, or maxReceiveCount. The same guarantee Tonder spent an entire AccountUpdateQueue + version counter to approximate is just true here. See the big shift.