Inbox pattern (idempotent consumer)
A consumer records the id of each processed message in the same transaction as its own change, and skips any id it has already seen.
It is the receiving half of the transactional outbox. Because delivery is at least once, the same event can arrive twice; an inbox table with a unique constraint on the message id turns the second delivery into a no-op. An alternative is to make the operation naturally idempotent, for example “set status to paid” instead of “add 100 to the balance”.
Related terms
- Idempotency (idempotency key): An operation is idempotent if doing it twice has the same effect as doing it once. Retries become safe.
- Transactional outbox: Saving an event to an outbox table in the same database transaction as the change itself, then publishing it to the broker separately.
- Exactly-once delivery: The promise that each message has its effect once; in practice, at-least-once delivery plus processing that ignores duplicates.
