Design the write path for 'checkout places an order and, separately, sends a confirmation email' so that an email outage can never fail the checkout, and the event announcing the order can never silently go missing. What's the mechanism, and what does it not solve?

Split the work by the test "does the caller need this to continue?" — saving the order and reserving stock are synchronous, because the order doesn't exist without them; the confirmation email is a consequence of the order existing, not a condition for it, so it moves to an asynchronous consumer driven by an OrderPlaced event. That alone introduces a new gap: writing to the database and publishing to a broker are two separate operations with no shared transaction, so the process can crash between them and either lose the event or double-publish it. The transactional outbox closes that gap: write the event as a row in an outbox table in the same database transaction as the order, and have a separate relay publish outbox rows to the broker afterward. It doesn't solve exactly-once delivery — the relay can publish twice after a crash, so the email consumer still has to be idempotent, which every consumer needs anyway since brokers deliver at least once regardless.