The Outbox Pattern isn't really about messaging. It's about eliminating an impossible atomicity assumption: “I'll update my database and then publish the event.” This visual shows what actually happens when failure occurs between those two operations, and why idempotency is still required.
The invariant is a committed business change must not become disconnected from the event describing that change. The application therefore commits the business record and outbox record in one local transaction; a relay or CDC process publishes the committed outbox event asynchronously. This is a solution to the distributed-system dual-write problem.
The subtle point is that Outbox does not magically create exactly-once processing. Publication can still be retried and consumers should remain idempotent.
Use unique event ID for deduplication and uses the aggregate ID as the event key, which matters for preserving aggregate ordering in Kafka partitions.
At 10× scale, the interesting bottleneck frequently moves from the broker to the outbox table and publisher: polling frequency, indexes, cleanup, CDC lag, payload size and partition-key distribution become architecture concerns.
Top comments (0)