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.
Backend and product engineers designing software behavior.
Your approach: Use diagrams, tables or prose for customer contracts, state transitions and data ownership; include APIs only to the depth the question requests.
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.
Resolve the scoping questions for Transactional Outbox. Separate stated behavior from assumptions, and identify what is outside your design.
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.
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?
Identify users, required behavior and exclusions. Answer: Which business write must cause an event? What should happen if the writer stops immediately after committing?
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?
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.
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.
Walk through a difficult case step by step, including detection and recovery. Consider: How will operators detect and recover a growing delivery backlog?
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.