Outbox Pattern: Reliable Event Publishing with Spring Boot
Fast recall
Quick revision
Core answer
Whether you understand the dual-write problem in distributed systems and know a production-proven solution
Not knowing why 'save to DB then publish to Kafka' is unreliable — the broker publish can fail after the DB commit, leaving events unpublished
Mention Debezium CDC as an alternative to polling, discuss idempotency keys in the outbox table, and explain how to handle ordering guarantees
Interview-ready guide
Interview answer
The Outbox pattern exists because of a crash window most developers don't think about.
- You save an order to PostgreSQL, then publish an event to Kafka — two operations that look safe individually.
- But if the application crashes between those two lines, the order exists in the database but the event was never published.
- Inventory never gets reserved.
- The confirmation email never sends.
How the Outbox pattern works:
- Write the event into an outbox table in the same database transaction as the business entity — if the order commits, the outbox row commits; if either fails, both roll back; there is no window where one exists without the other
- A separate process — either a scheduled poller or Debezium CDC — reads unpublished outbox rows and sends them to Kafka, then marks them published
- If the relay process crashes after Kafka acknowledges but before updating the row, the next cycle publishes again — this is why downstream consumers must be idempotent
Partition key and ordering:
- Use the aggregate ID as the Kafka partition key — all events for order #123 land on the same partition, preserving causal ordering so
OrderPlacedalways arrives beforeOrderShipped - The partition key choice is critical for consumers that need to maintain state per entity
Polling vs Debezium:
- Polling is simpler — a
@Scheduledmethod querying for rows wherepublished_atis null, every 500ms - Debezium tails the PostgreSQL WAL and delivers events in under 100ms, but it requires a Kafka Connect cluster and WAL retention monitoring
- The retention window matters: schedule deletion of published rows older than 7 days to prevent unbounded table growth
I recommend starting with scheduled polling and moving to Debezium only when event freshness or database polling load becomes a measurable bottleneck.
Outbox Pattern: Reliable Event Publishing with Spring Boot
Direct Answer
The outbox pattern solves the dual-write problem by writing both the business entity and the outgoing event to the same database transaction. A separate process (poller or CDC with Debezium) reads the outbox table and publishes events to the broker, ensuring events are never lost even if the broker is temporarily unavailable.
Common Mistakes & Pitfalls
Not knowing why 'save to DB then publish to Kafka' is unreliable — the broker publish can fail after the DB commit, leaving events unpublished
Check your understanding
Answer these without looking back at the article.
- How does Debezium differ from polling the outbox table, and when would you choose each?
- How do you handle outbox table cleanup to prevent it from growing indefinitely?
- What happens if the outbox poller publishes the same event twice — how do consumers handle this?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.