In a complete event-driven system, what guarantees the event store and application database stay consistent when a command handler needs to both persist state and publish an event?

The transactional outbox pattern provides this guarantee. Instead of persisting state and publishing an event as two separate, independently-failing operations, the command handler writes the state change and an outbox record describing the event to be published in the same local database transaction — so both succeed together or neither does. A separate process then reads unpublished outbox records and publishes them as real events, retrying until publication succeeds, and marks them published once it does. This closes the dual-write problem: without it, a crash between persisting state and publishing the event can leave the database and event stream disagreeing about what actually happened, which quietly breaks the assumption that the event store is the single, authoritative source of truth everything else in the system depends on.