What remains after the failed first attempt at shipping?

The confirmed order and the open outbox entry O-8; the relay can send again later.

The news channel is unavailable for hours. What happens to B-1042?

The order remains confirmed, and O-8 Stay open. Once the channel is reachable, the relay can publish.

Should order publish itself immediately after the commit, without outbox? How do you weigh up?

This saves table and relay. However, a failure between commit and publication loses the message. The outbox costs more building blocks, gets the intention for it.

PatternChapter II · Communication · Building block 6 of 9

Transactional Outbox

Transactional Outbox stores a business change and its shipping intent in the same local transaction. A relay then publishes open entries.

By Michael Meierhoff · Meierhoff Systems

Outbox entryIntent to ship in the database.
RelayPublishes open entries later.
Renewed attemptEntry remains open until handover.

Context

Why this is important

If stored first and then sent separately, a failure in between can lose the message. The Outbox stores intention and change together. The distribution of messages is a separate building block.

This building block explains atomic storage before publication. For the distribution of published news see Queues, Pub/Sub & Streams.

At a glance · Data and Event in a Transaction

The service writes data and outbox entry together; a relay reads the outbox and forwards the event to the broker.

Shop example · Sequence of time

From commit to later publication

Variant with permanent news channel: order confirmed B-1042 and at the same time stores order confirmed in your outbox. The news channel is temporarily unreachable.

This is how you read the picture

Outbox entry The message “B-”1042 + Outbox O-8“ in a local transaction.”
Relay The track Relay: "read open outbox" and "O-"8 publishing.
Renewed attempt ‘O-8 Republish" after the failure; only afterwards "mark as shipped.

OrderDatabaseRelayNews channel

Step 1 of 6 · Order → Database

B-1042 + Outbox O-8

A local transaction

The broker failure is after the local commit; the open entry is retained for another attempt.

Benefits & limitations

Helps if:

A local transaction stores the business change together with the message request, preserving the intent to send it durably.
Separate commit boundaries for the database and message broker make a relay with pending records a durable bridge to publication.
Observable progress and permanent error states make retriable delivery after a crash manageable in production.

Boundaries

The relay delivers at least once; recipients must tolerate duplicates, for example through Idempotency.
Delivery is delayed, and the outbox table needs cleanup and backlog monitoring.
The outbox safeguards the local intent to send; Pub/Sub and Streams governs distribution and retention.

In practice

Write the business change and outbox record in the same local transaction. The relay reads pending records, sends them and records progress only after successful publication.
Bound relay retries and store the delivery status and failure cause. A permanent failure needs an alert, investigation and controlled release for retry rather than endless attempts.
Recipients must recognise repeated deliveries because a relay can crash after sending. Idempotency addresses this; Transaction boundaries explains local coupling.

Read the detailed explanation

The process has two phases: first, the local database transaction commits the business change together with the publication record. A separate relay then reads pending records, publishes their messages and records its progress. A temporarily unavailable broker leaves the stored delivery requests intact.

A relay can fail after publication but before recording its progress, causing it to send the same record again. Recipients must therefore handle duplicates. Permanently failing records need a visible error state, alerting and a controlled recovery process.

Transaction boundaries safeguard the change and delivery request together locally; Delivery guarantees describe what remains unresolved after handover to the transport.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
What remains after the failed first attempt at shipping?
View the solution with justification
The confirmed order and the open outbox entry O-8; the relay can send again later.
ApplyingTransferred to a new situation
The news channel is unavailable for hours. What happens to B-1042?
View the solution with justification
The order remains confirmed, and O-8 Stay open. Once the channel is reachable, the relay can publish.
EvaluateWeighing an alternative
Should order publish itself immediately after the commit, without outbox? How do you weigh up?
View the solution with justification
This saves table and relay. However, a failure between commit and publication loses the message. The outbox costs more building blocks, gets the intention for it.

Explore further

These optional deepenings complement the learning goal of this page.

Change Data Capture and Polling

The relay can poll outbox records regularly or capture their changes from the transaction log using Change Data Capture. Both approaches build on the business change and outbox record stored together.

In the shop, the relay uses this mechanism to publish the stored order message. Recipients must handle repeated deliveries with Change Data Capture too; the shared local transaction and Idempotency retain their roles.

References

Continue on the learning path

Next in Communication & APIs: Orchestration & choreography.

9 Building blocks

Continue withOrchestration & choreography