Outbox Pattern
Writes domain event to same DB transaction as business data — reliable publish to message bus without dual-write bugs.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Outbox Pattern is non-negotiable.
① What it is (30 seconds)
Writes domain event to same DB transaction as business data — reliable publish to message bus without dual-write bugs.
② How it works in system design
INSERT order + INSERT outbox row in one transaction. Poller or CDC reads outbox, publishes to Kafka, marks sent. Guarantees at-least-once delivery to bus.
Typical placement
Client→Edge / Gateway→Outbox→Services→Data stores
③ Concrete system design example
Scenario: Payment captured: update payment row + outbox event PaymentCaptured in PostgreSQL commit. Worker publishes to Kafka for email receipt and analytics.
④ Important interview Q&A
| Question | Answer |
|---|---|
| Outbox vs dual write? | Dual write DB then Kafka can fail between — outbox atomic in one transaction. |
| Polling vs CDC? | CDC lower latency; polling simpler with indexed outbox table. |
| Duplicate publish? | Consumers idempotent on event_id. |
⑤ Seen in these system designs
- Payment System — webhooks
- Notifications — trigger events
- Notifications — reliable emit
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Same transaction
- Poller or CDC
- Idempotent consumers
- vs dual write failure