What problem are we solving?
In a distributed system, a sender does not always know whether a consumer processed a message. The connection may fail after processing, the acknowledgement may be lost, or the broker may deliver the event again.
That is why “at least once” delivery is useful for reliability but automatically creates a risk of duplicate business execution.
How Transactional Inbox works
The consumer stores the incoming message identifier together with the processing result or inside the same transaction boundary. Before processing a redelivery, it checks whether the message has already been seen.
If it has, the consumer can acknowledge the message without applying the business change again.
The idea is similar to API idempotency, but applied to asynchronous messages and events.
What the business gets
The main benefit is fewer financial and operational errors caused by redelivery. Transport reliability no longer conflicts with business correctness.
The company can let brokers and consumers retry aggressively after failures without turning recovery into a source of new incidents.
What the team gets
The team gets an explicit deduplication mechanism and can separate delivery guarantees from business idempotency.
Retries, replay, and recovery become easier to design because duplicate messages are treated as a normal scenario rather than an exception.
What the customer gets
Customers see fewer duplicates: repeated charges, orders, notifications, or state changes caused by technical retries.
The system can be persistent about delivery while remaining correct from the user’s point of view.
What do we pay for it?
Message identifiers must be stored and eventually expired, and the identifier has to remain stable and unique for the business operation.
If the Inbox record is stored separately from the business change, another inconsistency window appears. The transaction boundary still matters.
When it is unnecessary
If the operation is naturally idempotent and repeating it does not change the result, a dedicated Inbox may be unnecessary.
It is most valuable where duplicate execution has a real price: money, quotas, entity creation, external calls, or irreversible state changes.
Questions to ask before deciding
- Can the broker deliver the same message again?
- What happens if the operation runs twice?
- Does the message have a stable unique identifier?
- Can the processed marker and business change be stored atomically?
- How long must processed identifiers be remembered?
In the end
Reliable delivery does not mean exactly one execution. In real distributed systems, redelivery is normal and should be designed for.
For the business, Transactional Inbox is valuable because it lets the system recover persistently without executing the same business operation twice.