You've got a database and a message queue, and you need both to agree. Commit to the database, publish the message, and either can fail after the other succeeds. This is the dual write problem, and the outbox pattern is the textbook answer: write the message to a table in the same transaction as your data, then publish it separately. Every messaging talk mentions it. Almost none show what it takes to run in production.

The outbox only solves half the problem. Publish reliably and your consumers still have to handle redelivery, out-of-order messages, and duplicate processing, which is where the inbox pattern comes in. Get either half wrong and production starts double charging customers or silently dropping messages.

In this session, we'll build both patterns from scratch using popular tools such as Entity Framework Core, a background job runner, and a message broker like Azure Service Bus or RabbitMQ. We'll compare polling against log-tailing for the outbox, and build idempotent consumers with dedup keys for the inbox. Finally, we'll look at the delivery guarantee you're actually left with end to end, at-least-once not exactly-once, and the failure modes that never make it into the blog post: poison messages, table growth, clock skew.