Exponential backoff

Wat is exponential backoff?

Exponential backoff is een retry-strategie waarbij je na elke mislukte poging langer wacht voor je opnieuw probeert. De wachttijd groeit bijvoorbeeld van 1 seconde naar 2, 4, 8 en 16 seconden.

Je gebruikt dit bij tijdelijke fouten: een API geeft even geen antwoord, een database is overbelast, of een SaaS-platform stuurt een rate limit terug. Meteen blijven proberen maakt het probleem vaak erger. Backoff geeft het andere systeem ruimte om te herstellen.

Het idee is simpel: probeer opnieuw, maar met geduld.

Hoe werkt exponential backoff?

Een retry policy legt vast hoeveel pogingen je doet en hoe lang je wacht tussen pogingen.

Pseudocode
attempt 1: wacht 1 seconde
attempt 2: wacht 2 seconden
attempt 3: wacht 4 seconden
attempt 4: wacht 8 seconden
stop na 5 pogingen

In echte code voeg je vaak jitter toe: een kleine willekeurige variatie op de wachttijd. Zonder jitter proberen duizend clients misschien allemaal exact na 8 seconden opnieuw. Met jitter spreid je die druk.

Wanneer gebruik je exponential backoff?

• Bij tijdelijke netwerkfouten. Een korte time-out hoeft geen definitieve mislukking te zijn.

• Bij rate limits. API's vragen soms expliciet om trager te proberen.

• Bij message queues. Een bericht dat faalt, kan later opnieuw verwerkt worden met oplopende vertraging.

• Bij datapijplijnen. Een bron of doel kan even niet beschikbaar zijn zonder dat de hele job moet falen.

Exponential backoff versus gewone retry

Een gewone retry probeert na een vaste wachttijd opnieuw, of zelfs meteen. Dat is eenvoudig, maar kan een overbelast systeem extra belasten.

Exponential backoff vergroot de afstand tussen pogingen. Dat vermindert druk en geeft tijdelijke fouten meer kans om vanzelf te verdwijnen. Het nadeel is dat herstel soms langer duurt, omdat je bewust wacht.

Waar moet je op letten bij exponential backoff

• Retry alleen veilige acties. Een dubbele betaling of dubbele e-mail is erger dan een foutmelding. Maak acties idempotent.

• Zet een maximum. Oneindig blijven proberen verbergt fouten en kan wachtrijen vullen.

• Gebruik jitter. Dat voorkomt dat veel clients tegelijk opnieuw proberen.

• Combineer met circuit breakers. Als een systeem duidelijk stuk is, stop dan tijdelijk met proberen in plaats van elke request door retries te sturen.

FAQ over exponential backoff

1. Wanneer retry je niet?
Bij permanente fouten, zoals foutieve credentials of een validatiefout. Die lossen niet op door te wachten.

2. Wat is een goede maximumwachttijd?
Dat hangt af van je proces. Een interactieve API heeft seconden nodig, een nachtelijke datapijplijn kan minuten verdragen.

3. Is exponential backoff genoeg voor betrouwbaarheid?
Nee. Je hebt ook idempotentie, logging, monitoring en soms een dead-letter queue nodig.