Exactly-once processing

Wat is exactly-once processing?

Exactly-once processing is de garantie dat elk event precies één keer doorwerkt in het resultaat, ook als het systeem onderweg faalt en berichten opnieuw stuurt. Komt een bestelling binnen, dan telt ze één keer mee in de omzet: niet nul keer omdat er iets verloren ging, en niet twee keer omdat een retry hetzelfde bericht nog eens afleverde.

Het gaat om het effect, niet om hoe vaak een bericht over de lijn gaat. Een betaling mag technisch drie keer aankomen, zolang de klant maar één keer afgerekend wordt. Verwerk je hetzelfde verkoop-event twee keer, dan boek je je voorraad dubbel af en verkoop je iets dat er nog ligt. Exactly-once telt dus zodra er geld of tellingen meespelen, en zeker bij streaming data en Change Data Capture, waar events onafgebroken binnenstromen.

Waarom exactly-once lastig is in een distributed systeem

De kern van het probleem is een verloren bevestiging. Een producer stuurt een bericht naar de broker, de broker schrijft het weg en stuurt een ack terug. Gaat die ack onderweg verloren, dan zit de producer met een vraag zonder antwoord: is mijn bericht aangekomen en is enkel de bevestiging weg, of is het bericht zelf nooit geland?

Voor de producer zien die twee gevallen er identiek uit. Stuurt hij niet opnieuw, dan riskeert hij verlies. Stuurt hij wel opnieuw, dan riskeert hij een dubbel. Dat is precies de spanning tussen at-most-once en at-least-once. Exactly-once haal je dus niet door beter je best te doen op het netwerk, maar door een mechanisme dat een dubbel bericht herkent en negeert, en dat verwerking en wegschrijven als één geheel behandelt.

Hoe bereik je het in de praktijk?

In het kort: je levert at-least-once af en zorgt dat dubbel verwerken geen dubbel effect heeft. Dat heet ook wel "effectively once". Twee bouwstenen maken het waar.

Idempotente producers. Apache Kafka geeft elke producer een intern id en nummert elk bericht met een oplopend sequentienummer. Herkent de broker een nummer dat hij al had, dan schrijft hij het niet nog eens weg. Zo verdwijnt de dubbel van een retry. Dit is idempotentie ingebakken in de transportlaag.

Transacties over de verwerking heen. Bij een lees-verwerk-schrijf-lus wil je dat drie dingen samen slagen of samen falen: het resultaat wegschrijven, de toestand bewaren, en de leespositie (de offset) verzetten. Kafka bundelt die in één transactie; slaagt ze niet, dan wordt niets zichtbaar en herbegint de verwerking vanaf de laatst bevestigde positie. Kafka Streams regelt dit met processing.guarantee op exactly-once, Apache Flink met checkpoints die de output pas zichtbaar maken zodra de momentopname rond is.

De keten is maar zo sterk als de sink

Hier zit de valstrik die vendor-pagina's graag weglaten: exactly-once binnen de broker is niet hetzelfde als exactly-once tot in je eindsysteem. Zodra de data je warehouse, database of API binnengaat, moet die eindbestemming (de sink) meespelen.

Dat vraagt twee dingen. De sink moet transacties of een idempotente schrijfactie ondersteunen, zodat een herhaalde levering geen tweede rij aanmaakt. En de lezer aan het einde moet enkel bevestigde data zien: bij Kafka is dat isolation.level op read_committed. Ontbreekt een van de twee, dan heb je exactly-once tot halverwege en dubbels aan het einde. Daarom bouw je in de praktijk bijna altijd een idempotente sink: een upsert op een natuurlijke sleutel, of een dedup-tabel met reeds verwerkte event-ids.

At-most-once, at-least-once en exactly-once naast elkaar

At-most-once
Hoogstens één keer aan. Faalt er iets, dan kan een bericht verloren gaan en komt het niet terug. Geen dubbels, wel mogelijk verlies. Prima waar een gemiste meting niet erg is, zoals een sensor die toch elke seconde meet.

At-least-once
Minstens één keer aan, en soms vaker. Niets gaat verloren, maar je krijgt dubbels bij een retry. Dit is de standaard van de meeste streamingplatformen, en bruikbaar zodra je verwerking idempotent is.

Exactly-once
Precies één keer doorgewerkt in het resultaat. Geen verlies, geen dubbel effect. Het duurste en het lastigste om te bouwen, en het loont enkel waar een dubbele of gemiste telling echt geld of vertrouwen kost, zoals bij betalingen en voorraad.