A command handler for `PlaceOrder` first commits the new order state to its database, and then, as a second separate step, publishes the resulting `OrderPlaced` event to a message broker. What failure mode does this two-step design create, and what are the common ways teams close that gap?

## The dual-write problem The dual-write problem arises whenever a single logical operation needs to durably affect two independent systems — here, a relational database holding the order state and a message broker that will notify downstream consumers — and there is no shared transaction coordinator spanning both. Concretely, the handler first commits the order row inside its own database transaction; that commit either fully succeeds or fully rolls back, and the database's own guarantees end right there. The handler then, as a wholly separate operation, calls the broker's publish API. Between those two steps sits a window during which: - **the process can crash**, - **the network to the broker can fail**, or - **the broker itself can be unreachable**. If anything goes wrong in that window, the database commit has already happened and cannot be un-done just because the publish failed — the order genuinely exists — yet no `OrderPlaced` event was ever delivered, so every downstream consumer that should have reacted to it never will, silently and with no error surfaced anywhere obvious. ## Why it matters, and why it exists at all This failure mode matters because CQRS and event-driven systems depend on the event stream being a **faithful, complete record** of everything that happened to the write side; a single silently dropped event breaks that contract in a way that's very hard to detect after the fact, since there's no error, no exception, nothing in a log unless someone specifically instrumented the gap. The problem exists fundamentally because most relational databases and most message brokers are separate systems with separate commit protocols, and genuinely distributed two-phase-commit transactions across the two — even where technically possible — are rare in practice because of the operational complexity, latency cost, and the fact that many popular brokers, such as Kafka, don't support XA-style distributed transactions with arbitrary external resource managers in the first place. ## The transactional outbox The standard resolution, the transactional outbox pattern, works by turning the second write into a write against the same database as the first. Instead of calling the broker directly inside the handler, the handler writes a row describing the event — its type, payload, and an ordering key — into an 'outbox' table, in the exact same local database transaction that commits the order state change. Because both writes are now against the same database in the same transaction, they succeed or fail together with full ACID guarantees; there is no window where one happens and the other doesn't. A separate, independent process then takes responsibility for actually getting that row to the broker: - **a poller** that periodically queries for unsent outbox rows, or - **a change-data-capture connector such as Debezium** that tails the database's write-ahead log and streams new outbox rows to the broker as they're committed. That relay process retries until the broker acknowledges receipt, and only then marks the row as sent or deletes it. ## The trade-off The trade-off is added infrastructure and a shift in where complexity lives: - **an outbox table** to maintain and eventually prune, - **a relay process** that itself needs monitoring, and - **critically, a new obligation pushed onto every consumer of the resulting events** — because the relay guarantees only at-least-once delivery, not exactly-once, a crash between publishing to the broker and marking the outbox row as sent will cause a redelivery on restart, so every downstream consumer must now be idempotent to duplicate `OrderPlaced` events, which is the same idempotency discipline command handlers need for duplicate commands, just moved to the event-consuming side. ## Event sourcing answers it structurally Event sourcing offers a structurally different answer to the same class of problem: if the events themselves are the durable state, with no separate 'current state' row committed independently, then there is only ever one write to make durable — appending to the event store — and publishing to consumers can be done by tailing that same append-only log, so there's nothing left to diverge in the first place. That said, event sourcing brings its own substantial costs, like rebuilding read models from event streams and handling event schema evolution, so it's not a drop-in replacement for the outbox pattern in a conventional state-stored system. ## A well-known instance A well-known real-world instance of this exact pattern is Debezium's outbox event router, built specifically to consume outbox-table rows via CDC and republish them to Kafka, which several production systems adopt precisely because it decouples the reliability guarantee, at-least-once delivery from a committed database row, from the application code's own retry logic, letting the database's own durability do the heavy lifting instead of hoping an in-process publish call never fails at the wrong moment.