Transactional Outbox

Outcome: Design or review Transactional Outbox for this system while keeping data correct, secure, and easy to operate. User context: Checkout saves order `984` and outbox event `OrderCreated:984` in one transaction. A relay publishes the event later. If it stops after sending but before marking the row, it may send again. The consumer removes the duplicate by event ID. Technical concept or control: Transactional Outbox. Why it fits: Use it when a committed database change must reliably lead to a message or event. Keep the outbox in the same transaction and operate the relay as its own reliable process. Do not use it when: Do not call it one-time delivery or one transaction across services. Plan for repeated events, their order, relay delay, cleanup, and safe duplicate handling. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.