Outbox pattern: multiple-choice review
Multiple-choice synthesis across the outbox unit — the dual-write gap, the single-transaction fix, polling vs CDC relays, at-least-once delivery, and the operational tax.
Six questions that cut across the whole unit. Each one mirrors a decision you make in a real incident — not a definition to recite, but a tradeoff to weigh when a write and a publish must both land.
Confirm you can connect the dual-write gap, the single-transaction fix, the polling-vs-CDC relay choice, the at-least-once guarantee, and the operational tax — the synthesis the lesson built toward.
A handler runs INSERT order, then kafka.publish('OrderPlaced'). The pod is OOM-killed after the commit but before the publish returns. What is the resulting failure, and why can't try/catch save you?
Why does writing the business row and an outbox row in one local transaction give atomicity 'for free', where 2PC across Postgres and Kafka does not?
A team runs a polling relay at a 1s interval and wants events to land faster. They consider dropping to a 25ms poll. What is the senior read on this?
Why is the outbox at-least-once rather than exactly-once, and what does that force on every consumer?
You scale the polling relay from one replica to three for throughput and immediately see every event published roughly three times. What is the fix?
The outbox table has grown to several hundred thousand rows, polling queries are slowing, and a nightly DELETE of old sent rows causes lock contention with inserts. What is the better cleanup design?
Across the unit the through-line is one chain: a dual write across two stores has no crash-safe ordering, so you collapse it into a single local transaction that writes the business row and an outbox row together. A separate relay ships those rows — polling (simple, but interval-bounded latency and constant DB load) or CDC (single-digit-ms, near-zero table load, at operational cost). Because the relay publishes then marks sent in two steps, delivery is at-least-once, so consumers dedupe on a stable event id. The operational tax — table bloat, ordering under parallel relays, competing replicas — is paid with partitioning, batched reaps, aggregate keying, and FOR UPDATE SKIP LOCKED. Now when you review a service that must write a DB and notify a broker, you know which of these six failure modes to look for first.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.