Transactional outbox
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
make "change state" and "record the event" one atomic step.
Planned topics
- Write the business row and an outbox row in the same local transaction. Either both exist or neither.
- A separate relay reads unsent outbox rows and publishes them, then marks them sent.
- Delivery becomes at-least-once: the relay may publish, crash, and publish again. Consumers must cope (L04).
- Keep the outbox row small: event id, aggregate id, type, JSON payload, created time, sent flag.
- Use the aggregate id as the Kafka key so one order's events stay ordered.
Draft outline details
Demonstration
CREATE TABLE outbox (
id UUID PRIMARY KEY, aggregate_id BIGINT NOT NULL,
type TEXT NOT NULL, payload JSONB NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(), sent_at TIMESTAMPTZ);@Transactional
void place(Order o) { repo.save(o); outbox.save(OutboxEvent.of("OrderPlaced", o)); }Check your understanding
Why is the outbox write safe where kafka.send was not?
Show answer
It is in the same database transaction as the order.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.