Write the domain event to an outbox table in the same database transaction as the business entity write. A separate relay service polls the outbox and publishes unpublished events to Kafka, then marks them as published. This guarantees the event is eventually published even if the app crashes between the write and the publish.

Outbox entity, transactional write, and relay publisher

Outbox pattern guarantees and design notes:

1
The event and business entity are written atomically — no event is lost even if the process crashes after the DB write.
2
The relay is idempotent — if it crashes mid-relay, unpublished events are picked up on the next poll.
3
Use a distributed lock (Redis SETNX) if multiple relay instances run concurrently to prevent duplicate publishes.
4
Mark events as published after Kafka confirms receipt — not before.
5
Add a dead-letter column for events that fail repeatedly so operators can inspect and replay them.

Difficulty: 7/10

Topics: outbox pattern, Kafka exactly-once, NestJS transaction management

Scenario Questions

0-2 years experience

1
Suppose you need to write a NestJS service that creates a new order and publishes an 'order.created' event to Kafka. How would you use the outbox pattern to ensure the event is only sent if the order is successfully saved?
2
If the outbox table contains a row that hasn't been processed yet, what will happen when your background worker picks it up and the Kafka broker is temporarily unavailable?
3
Can you walk me through the steps your code would take from receiving the HTTP request to committing the outbox record?

2-5 years experience

1
We have a microservice that writes to Postgres and then publishes to Kafka using the outbox pattern. Lately, some messages are being duplicated after a service restart. What could cause that and how would you fix it?
2
Imagine you need to add a new field to the outbox payload without breaking existing consumers. How would you evolve the schema while keeping exactly‑once semantics?
3
During a load test, the outbox processing thread becomes a bottleneck. What trade‑offs would you consider to improve throughput while preserving ordering guarantees?

5-8 years experience

1
Design a scalable outbox processing component for a NestJS application that handles millions of events per day. Discuss partitioning, idempotency, and how you would monitor delivery failures.
2
How would you integrate Kafka's transactional producer API with NestJS's TypeORM transaction to achieve exactly‑once delivery across the database and Kafka?
3
If a downstream consumer crashes after processing a message but before committing its offset, how does your outbox design prevent duplicate processing, and what additional safeguards would you add?

8+ years experience

1
Our organization is moving from a monolith to multiple NestJS services that all use the outbox pattern with a shared Kafka cluster. What architectural guidelines would you set to avoid cross‑service ordering issues and to standardize outbox implementations?
2
We have legacy services that directly publish to Kafka without an outbox. How would you plan a migration strategy that minimizes downtime and ensures exactly‑once semantics across the whole system?
3
Consider long‑term maintenance: how would you version the outbox schema and handle data migrations without losing in‑flight messages, especially when multiple teams own different services?

Follow-up Questions

❓What would you do if the database transaction commits but the Kafka publish fails?
❓How do you ensure the outbox worker doesn't reprocess already‑sent messages after a crash?
❓Can you explain the trade‑offs between using Kafka transactions versus idempotent producers in this setup?