Exponentiële backoff is een herhaalstrategie waarbij de wachttijd tussen pogingen elke keer groeit als een aanvraag mislukt. Probeer één keer en faal, wacht één seconde. Faal opnieuw, wacht twee. Dan vier, dan acht. De gaten lopen snel op, wat een worstelend systeem behoedt voor een lawine aan herhaalde aanvragen.
Zie het als een vriend bellen die in gesprek is. Je drukt niet elke seconde opnieuw; je wacht even, dan iets langer, zodat hij tijd heeft om op te hangen. Exponentiële backoff is dat gevoel omgezet in een regel die een computer precies volgt. Het past natuurlijk bij herhaallogica, die bepaalt of je überhaupt opnieuw probeert, en bij throttling, die beperkt hoe snel je aanvragen verstuurt.
De meeste echte implementaties voegen een kleine willekeurige vertraging toe, jitter genoemd. Zonder die jitter zou elke client die op hetzelfde moment faalde óók op hetzelfde moment opnieuw proberen, precies de file die backoff wil voorkomen. Mét jitter spreiden de herhalingen zich en vlakt de belasting af. Backoff heeft ook een plafond nodig, of twee. Het ene begrenst hoe lang één wachttijd mag worden, zodat je niet ineens een uur tussen pogingen zit. Het andere begrenst hoe vaak je überhaupt opnieuw probeert. Na vijf pogingen tegen een betaal-API die nog steeds plat ligt, helpt een zesde zelden. Op dat punt is de slimme zet om te stoppen en het mislukte item aan een mens of een wachtrij te geven, in plaats van stil op de achtergrond te blijven loopen. Zie het als een koerier voor een dichte deur: kloppen, wachten, nog eens kloppen met langere tussenpozen, maar na een paar keer een briefje achterlaten in plaats van de hele middag te blijven staan. Goed afgesteld maakt het hele patroon van een wankele verbinding geen bron van verloren taken, maar een kleine vertraging die niemand opmerkt.
Bij TopDevs bouwen we exponentiële backoff in elke koppeling die met een externe API praat, zodat een korte hapering aan de andere kant nooit uitgroeit tot een reeks mislukte taken.
