30. Transactional Outbox

The brief

Transactional Outbox. A service commits to its database and then publishes an event. If it dies in between, the row exists and no one hears about it. Publishing first has the mirror problem: an event for a write that never happened. There is no ordering of two independent systems that makes this safe. Work from the scoping questions below. State assumptions for any unspecified load, guarantee or target, then trace your design end to end. Explain one difficult case and a credible alternative; the worked example is a reference, not a required implementation.

• Set the scope: Which business write must cause an event? What should happen if the writer stops immediately after committing?
• Define the contract: Can the receiver process a repeated event safely? Does event order matter globally or only for one business object?
• Test the boundaries: How will operators detect and recover a growing delivery backlog?

Constraints

Explicit scope and guarantees

Resolve the scoping questions for Transactional Outbox. Separate stated behavior from assumptions, and identify what is outside your design.

Supported operating targets

Declare relevant volume, latency, freshness, quality or cost targets with units. Show calculations or an evaluation plan that can test them; unspecified targets are your assumptions, not hidden pass criteria.

Failure and boundary behavior

Explain how your guarantees hold in a difficult case relevant to this subject. Address: Does event order matter globally or only for one business object? How will operators detect and recover a growing delivery backlog?

What to cover

1. 01

   Scope and behavior contract

   Identify users, required behavior and exclusions. Answer: Which business write must cause an event? What should happen if the writer stops immediately after committing?

2. 02

   State and interfaces

   Define the information owned by the system and the inputs, outputs and errors at its boundaries. Resolve: Can the receiver process a repeated event safely? Does event order matter globally or only for one business object?

3. 03

   Capacity and operating targets

   Estimate the dominant workload and resource demand with units and explicit assumptions. For a learned system, also state how quality is measured and what data is available.

4. 04

   Architecture and central flow

   Draw or describe the responsibilities needed for Transactional Outbox. Trace a representative request, event or job from its input to a visible result; identify durable state owners.

5. 05

   Failure and boundary walkthrough

   Walk through a difficult case step by step, including detection and recovery. Consider: How will operators detect and recover a growing delivery backlog?

6. 06

   Tradeoffs and operations

   Compare a credible alternative using your chosen workload and guarantees. Explain a remaining risk, a signal to watch and when you would change the design.

Worked designs

Explore the architecture and decisions, then build on an example with Coach.

Official design

Transactional Outbox

Write the row and the event it should publish in one transaction, then relay the event, so a commit and its message can never disagree.

Explore the design

Review rubric

AI feedback uses these criteria. Scores are practice feedback.