Queues, Streams, Eventing
Outbox pattern: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core mechanisms — the dual-write gap, the single-transaction fix, polling vs CDC, the at-least-once guarantee, idempotent consumers, and the operational tax — without looking back at the lesson.
- 01Why does a handler that writes the database and publishes to a broker have no crash-safe ordering of those two calls?
- 02How does the transactional outbox convert the dual write into something atomic, and what exactly is durable after COMMIT?
- 03Compare a polling relay and a CDC relay along latency, load on the primary, and operational cost.
- 04Why is outbox delivery at-least-once rather than exactly-once, and what does that force on consumers?
- 05You scale the polling relay to multiple replicas. What two problems appear, and how do you solve each?
- 06What causes outbox table bloat and how do you reap it without hurting the hot write path?
If you could reconstruct each answer from memory, you hold the unit’s spine: a dual write across two stores has no crash-safe ordering; the outbox collapses it into one local transaction whose COMMIT durably records the intent to publish; a relay ships rows by polling (simple, interval-bounded) or CDC (fast, operationally heavier); the publish-then-mark gap makes delivery at-least-once, so consumers dedupe on a stable event id; and the operational tax — bloat, ordering, competing relays — is paid with partitioning or batched reaps, aggregate keying, and FOR UPDATE SKIP LOCKED.