A saga step's message handler receives the same 'PaymentCharged' event twice because the broker redelivered it after a timeout. What is the inbox pattern / idempotent consumer approach, and how does it prevent the handler from applying the event's effect twice?

## Why delivery is at-least-once Saga steps communicate over messaging infrastructure — brokers, queues, or the outbox relay described elsewhere — that virtually always provides at-least-once delivery rather than exactly-once. This isn't a design flaw; exactly-once delivery across a network is not achievable in general (you can't distinguish "the ack was lost" from "the message was lost" without extra bookkeeping), so brokers and relays choose to occasionally redeliver rather than risk ever silently dropping a message. Consequences: - a consumer's ack can be lost after it already processed a message, causing the broker to redeliver it; - an outbox relay can crash after publishing but before marking a row sent, republishing it on restart; - or a consumer's own processing can succeed but crash before it acknowledges, again causing redelivery. Any of these means a saga participant's handler for, say, `PaymentCharged`, must be prepared to receive that exact event more than once. ## What redelivery costs you Without protection, redelivery causes real damage: an Inventory service reacting to `PaymentCharged` by decrementing stock would decrement twice for one actual payment, or a Notification service would send the customer two "your payment succeeded" emails. ## How the inbox pattern works The **inbox pattern** (also called the idempotent consumer or idempotent receiver pattern) solves this the mirror-image way the outbox pattern solves the producer side. The consumer maintains an inbox table that records the unique ID of every message it has successfully processed (the ID typically comes from the producer — an event ID assigned when the outbox row was created, so it's stable across redeliveries of "the same" logical event). When a message arrives, the handler, within one local database transaction: 1. first checks whether that message's ID already exists in the inbox table; 2. if it does, treats this as a duplicate: it skips reapplying the business effect (and optionally returns whatever result was recorded from the first processing, for handlers that need to reply); 3. if the ID is not present, performs the business-data update and inserts the ID into the inbox table, all inside the same transaction. So — exactly like the outbox pattern — the business effect and the "I've now processed this" bookkeeping either both commit or neither does. There's no gap where a crash between "apply the effect" and "record that I applied it" can cause a subsequent redelivery to be misclassified. ## The main cost The main cost is the extra table and the requirement that the message carry a stable, unique identifier the consumer can dedupe against — if a producer assigns a new random ID to a retried event where a stable ID could have been reused, deduplication silently breaks, so the outbox and inbox conventions need to agree on what counts as the same logical event. The inbox table also needs the same housekeeping as an outbox table — old entries eventually need to be purged, usually after a retention window comfortably longer than the maximum plausible redelivery delay, since keeping every processed message ID forever is unbounded growth. ## What outbox-plus-inbox actually buys you It's worth being precise about what this buys you: outbox-plus-inbox does not give you true exactly-once semantics in the abstract distributed-systems sense — it gives you **effectively-exactly-once** processing, built from two independently at-least-once legs (reliable publish via outbox, reliable dedupe via inbox) plus an idempotency check at the boundary. This is a well-established and sufficient pattern for the vast majority of saga use cases, and it's notably cheaper and simpler than trying to achieve true exactly-once delivery, which generally isn't achievable across independent systems without this exact kind of application-level bookkeeping anyway. ## A concrete failure mode A concrete failure mode without the inbox pattern: a Payment service publishes `PaymentCharged` via its outbox; the relay publishes it to Kafka but crashes before marking the outbox row sent, so on restart it republishes the same event. If the Inventory service's consumer isn't idempotent, it decrements stock a second time for a single real payment, silently under-counting available inventory — a class of bug that's notoriously hard to reproduce because it only manifests on the (rare but inevitable) relay-crash timing window, and shows up in production as slow inventory drift rather than an obvious crash.