Retry policy

Wat is een retry policy?

Een retry policy is de afspraak die bepaalt wanneer een systeem een mislukte actie opnieuw probeert. Een API-call faalt, een webhook komt niet aan, een database is even druk. De vraag is dan: proberen we opnieuw, hoe vaak en met welke wachttijd?

Zonder retry policy faalt een proces te snel. Met een slechte retry policy kan het omgekeerde gebeuren: duizenden herhalingen maken een tijdelijk probleem groter.

Retries zijn dus geen detail. Ze bepalen of automatisering betrouwbaar aanvoelt wanneer de echte wereld even rommelig is.

Wanneer gebruik je retries?

• Tijdelijke netwerkfouten
  Een verbinding valt kort weg of een service antwoordt even niet.

• Rate limits
  Een API zegt dat je te snel gaat en vraagt om later opnieuw te proberen.

• Locks en drukte
  Een database of queue kan een bericht tijdelijk niet verwerken.

• Asynchrone verwerking
  Een externe partij heeft meer tijd nodig voordat de status beschikbaar is.

Hoe ziet een goede retry policy eruit?

Een goede policy heeft drie onderdelen: welke fouten komen in aanmerking, hoeveel pogingen doe je en hoe lang wacht je tussen pogingen. Niet elke fout verdient een retry. Een timeout wel, een ongeldig klantnummer niet.

Vaak gebruik je exponential backoff: de wachttijd wordt na elke poging langer. Eerst een paar seconden, dan tientallen seconden, dan minuten. Zo geef je het andere systeem ruimte om te herstellen.

Voor berichten in een queue eindigt een retry policy vaak in een dead-letter queue. Na een vast aantal mislukte pogingen wordt het bericht apart gezet zodat iemand de oorzaak kan bekijken.

Retry policy versus foutmelding

Een foutmelding zegt dat iets misliep. Een retry policy zegt wat het systeem daarna doet. In een handmatig proces kan een medewerker beslissen om later opnieuw te proberen. In automatisering moet je die beslissing vooraf ontwerpen.

Dat ontwerp moet ook rekening houden met idempotentie. Als dezelfde actie twee keer wordt uitgevoerd, mag ze niet per ongeluk twee facturen, twee mails of twee betalingen aanmaken.

Waar moet je op letten bij retries?

Maak fouten onderscheidbaar
Retry alleen tijdelijke fouten. Validatiefouten, ontbrekende rechten of verkeerde configuratie lossen zichzelf niet op.

Respecteer rate limits
Als een API een wachttijd teruggeeft, gebruik die dan. Anders maak je throttling erger.

Log elke poging
Zonder audit trail zie je alleen dat iets uiteindelijk faalde, niet hoeveel pogingen eraan voorafgingen.

FAQ over retry policies

1. Hoeveel retries zijn genoeg?
Dat hangt af van het proces. Voor realtime schermen wil je snel falen. Voor nachtelijke syncs mag je langer proberen.

2. Kan een retry schade veroorzaken?
Ja, als de actie niet idempotent is. Bouw daarom bescherming in tegen dubbele verwerking.