Exactly-once business meaning is not a broker feature
Delivery guarantees do not prevent duplicate business effects. Producer transactionality and consumer idempotency own that boundary.
A message broker can make strong claims about how records are written, ordered or delivered inside its boundary. The business effect usually crosses that boundary: an application transaction happened before publication, and a consumer changes another database, sends a notification or calls an external system afterwards.
That is why “exactly once” becomes misleading when it is treated as an end-to-end business guarantee.
The hard rule#
The producer owns the event meaning. Consumers own their processing state, idempotency and effects.
The rule creates two separate responsibilities. The producer must not lose the intent to publish after the business transaction commits. The consumer must not turn a retried delivery into a repeated business effect.
Neither responsibility can be delegated to the event schema or broker alone.
The producer boundary: transaction plus outbox#
Publishing directly after a database commit creates a dual-write gap. The database may commit and the publish may fail. Reversing the order creates the opposite gap: the event can exist for a transaction that later fails.
A transactional outbox records the business state and event intent in one commit. A separate relay publishes the outbox record and marks its progress. The relay is allowed to retry, which means duplicate delivery remains possible and must be handled by design.
The event envelope therefore needs a stable event identity, business aggregate identity, event type, occurrence time, producer, schema version and trace context. Broker offsets and retry counters remain observations about delivery; they do not become part of the event's meaning.
The consumer boundary: one effect per identity#
A consumer checks the stable event identity at the same boundary as its effect. That can mean an inbox table committed with a database change, an idempotency key accepted by an external API, or another mechanism with equivalent atomic behaviour.
The important property is testable: delivering the same event more than once produces one business effect, while the duplicate delivery remains observable.
This is different from discarding all repeated payloads. Two legitimate events may contain the same values. Identity—not payload similarity—defines the duplicate.
Replay is a governed operation#
Replay should name:
- the event range and reason;
- the schema interpretation used;
- the target consumer or isolated destination;
- the idempotency behaviour expected; and
- the evidence that determines whether replay is accepted.
Dead letters retain the original event and failure reason. Correcting and redriving them is a controlled state transition, not an instruction to skip the record or edit it in place.
Evidence to request#
- The business transaction commits with its outbox record.
- Relay interruption does not lose event intent.
- An incompatible schema fixture fails before release.
- A duplicated delivery produces one business effect.
- A dead letter preserves the original event and reason.
- A bounded replay can run into an isolated target and be reconciled.
Limitation#
These controls establish integrity of the publication and consumption boundaries. They do not by themselves establish real throughput, latency, broker failover or recovery time. Those require a representative environment and observed exercises.
The precise validation question is therefore not “does the broker support exactly once?” It is: where is event intent committed, where is effect identity committed, and what happens when every step is repeated?