Transactional outbox

Wat is een transactional outbox?

Een transactional outbox is een patroon om een databasewijziging en een uitgaand event betrouwbaar bij elkaar te houden. Je schrijft de businesswijziging en het event naar een outbox-tabel in dezelfde database-transactie. Een aparte worker leest die outbox en publiceert het event naar een message queue of broker.

Het patroon lost het dual-write probleem op. Als je eerst de order opslaat en daarna een event publiceert, kan de applicatie precies tussen die twee stappen crashen. Dan staat de order wel in de database, maar weet de rest van het systeem van niets.

Met een outbox staat het event al veilig naast de order voor de transactie commit. Publicatie mag daarna tijdelijk falen, zolang de worker later opnieuw probeert.

Hoe werkt het?

1. De applicatie start een database-transactie.

2. Ze wijzigt de businessdata, bijvoorbeeld een nieuwe order.

3. Ze schrijft in dezelfde transactie een rij naar outbox_events.

4. De transactie commit. Data en event zijn nu samen opgeslagen.

5. Een background worker leest ongepubliceerde outbox-events en stuurt ze naar de broker.

6. Na succesvolle publicatie markeert de worker het event als verzonden.

BEGIN;

INSERT INTO orders (order_id, customer_id, status)
VALUES (1001, 42, 'created');

INSERT INTO outbox_events (event_type, aggregate_id, payload)
VALUES ('OrderCreated', 1001, '{"order_id":1001}');

COMMIT;

De code hierboven is vereenvoudigd. In productie voeg je meestal tijdstippen, id's, retry-tellers en foutinformatie toe.

Wanneer gebruik je een transactional outbox?

• Bij eventgedreven architectuur. Andere services moeten betrouwbaar horen dat er iets gebeurde.

• Bij integraties met queues. Een database en broker delen meestal geen echte transactionele grens.

• Bij saga's. Elke lokale transactie kan een event publiceren waarmee de volgende stap start.

• Bij audit en synchronisatie. De outbox geeft een duidelijk spoor van wat nog verzonden moet worden.

Transactional outbox versus rechtstreeks publiceren

Rechtstreeks publiceren is eenvoudiger: update de database, stuur meteen het event. Dat is prima wanneer verlies of dubbel versturen geen schade doet.

De outbox is beter wanneer het event hoort bij een businessfeit dat niet verloren mag gaan. Je accepteert meer onderdelen: een outbox-tabel, een worker, retries en idempotente consumers. Daarvoor krijg je een veel betrouwbaardere koppeling tussen opslag en bericht.

Waar moet je op letten bij een transactional outbox

• Consumers moeten idempotent zijn. Een worker kan hetzelfde event twee keer publiceren, bijvoorbeeld na een timeout. Ontvangers moeten duplicaten aankunnen.

• Volgorde is niet vanzelf gegarandeerd. Als volgorde per order of klant belangrijk is, moet je die expliciet ontwerpen.

• Ruim oude outbox-rijen op. Bewaar genoeg historiek voor diagnose, maar laat de tabel niet eindeloos groeien.

• Monitor achterstand. Een groeiende outbox betekent dat publicatie hapert.

FAQ over transactional outbox

1. Garandeert dit exactly-once delivery?
Nee. Het helpt voorkomen dat events verloren gaan, maar dubbele verwerking blijft mogelijk. Daarom blijft idempotentie nodig.

2. Heb ik hiervoor Kafka nodig?
Nee. Het patroon werkt met verschillende brokers en queues. Het idee zit in de database-transactie en de outbox-worker.

3. Is dit hetzelfde als event sourcing?
Nee. Event sourcing bewaart alle domeinveranderingen als bron van waarheid. Een outbox bewaart events tijdelijk of operationeel om ze betrouwbaar te publiceren.