Transactional inbox

A transactional inbox uses durable message records to protect local processing against duplicate deliveries. In the variant described here, the record that a message was processed and its change to application data are saved in the same database transaction.

A fictional service with the consumer name report-worker receives message E-42. It inserts the combination of consumer and message ID into its inbox and increases a report counter from 6 to 7. Both changes commit together. A database uniqueness rule on this combination also protects against concurrently running instances. Checking first and then writing is insufficient on its own.

The crash point matters

If the transaction fails before commit, neither the inbox entry nor the counter change persists. If commit succeeds but the subsequent broker acknowledgement is lost, E-42 can arrive again. The existing entry then prevents another increment to 8. The acknowledgement to the broker is not itself part of this local database transaction.

Idempotency describes the safe effect of repetition; an inbox is one possible implementation pattern. An outbox instead stores outgoing messages together with the local change. An inbox alone cannot guarantee that an external HTTP call is executed or an email sent exactly once. Message ID retention must fit the possible redelivery and replay window; entries removed too early no longer protect against later duplicates.

Sources

• Chris Richardson: Handling duplicate messages using the Idempotent consumer pattern

• MassTransit: Transactional Outbox and Consumer Inbox