At-least-once delivery

Wat is at-least-once delivery?

At-least-once delivery is de garantie dat elk bericht minstens één keer aankomt. Verloren gaan doet het niet, maar dubbel aankomen kan wel. Zo werken de meeste message queues en streamingsystemen.

Het komt door de manier waarop de bezorging bevestigd wordt. De afzender stuurt een bericht en wacht op een ack, een bevestiging dat het aankwam. Blijft die ack uit, dan weet de afzender niet of het bericht verloren ging of dat alleen de bevestiging onderweg sneuvelde. Hij stuurt het dus opnieuw. Kwam het de eerste keer wel aan en ging enkel de ack verloren, dan heb je het bericht nu twee keer. Verlies sluit je op die manier uit, duplicaten niet.

Waarom is at-least-once de standaard?

Voor de meeste systemen is het de veilige middenweg. Data kwijtraken is bijna altijd erger dan een bericht twee keer zien, en een duplicaat kan je aan de ontvangende kant opvangen. Een verloren bericht kan je niet meer rechtzetten.

Je vindt die keuze terug bij de grote namen. AWS SQS standard queues bezorgen minstens één keer en waarschuwen dat er soms meer dan één kopie van een bericht aankomt. Google Cloud Pub/Sub levert standaard at-least-once en biedt exactly-once enkel als aparte optie. RabbitMQ geeft je at-least-once zodra je met acks werkt; zonder acks val je terug op at-most-once. En Apache Kafka staat standaard op at-least-once.

De drie bezorggaranties naast elkaar

Er zijn drie klassieke garanties, en ze verschillen op één punt: wat er gebeurt bij een fout.

• At-most-once. Hoogstens één keer. Bij een fout kan een bericht verloren gaan, maar het komt nooit dubbel. Snel en simpel, alleen accepteer je dat je af en toe iets mist.

• At-least-once. Minstens één keer. Een bericht gaat nooit verloren, maar kan bij een retry dubbel aankomen. De gangbare standaard.

• Exactly-once. Precies één keer, nooit verloren en nooit dubbel. Dat klinkt als het beste van beide, maar het vraagt coördinatie en werkt vaak enkel binnen één systeem. In de praktijk is exactly-once meestal at-least-once bezorging met idempotente verwerking eronder.

Wat vraagt at-least-once van je consumer?

Omdat een bericht dubbel kan binnenkomen, moet de kant die het verwerkt daartegen bestand zijn. Er zijn twee wegen: verwerk elk bericht idempotent, zodat twee keer verwerken hetzelfde resultaat geeft als één keer, of dedupliceer op een unieke sleutel, zodat je een bericht dat je al zag gewoon overslaat.

Neem een order-event. Je systeem krijgt "bestelling 8842 geplaatst" binnen, verwerkt het, maar de bevestiging naar de bron gaat verloren. De bron stuurt het event opnieuw. Verwerk je dat naïef, dan staan er nu twee bestellingen 8842 in je systeem, met een dubbele factuur tot gevolg. Gebruik je het order-ID als sleutel en doe je een upsert of een check tegen een dedup-tabel, dan verandert de tweede keer niets. Eén event, één bestelling, ook al kwam het twee keer toe.

Datzelfde principe zie je overal waar at-least-once speelt: bij streaming data, bij webhooks die retryen tot ze een 200 terugkrijgen, en bij Change Data Capture die databasewijzigingen doorstuurt als events. Het systeem zorgt dat er niks verloren gaat, de deduplicatie aan jouw kant zorgt dat een duplicaat niet dubbel telt.