technisch · antwoord met bronnen
Retries met exponential backoff
Retries met exponential backoff zijn een strategie voor foutafhandeling waarbij de wachttijd tussen opeenvolgende pogingen van een mislukte bewerking exponentieel toeneemt. In plaats van met vaste intervallen opnieuw te proberen, wacht het systeem na elke mislukking langer, zodat de ontvangende server tijd krijgt om te herstellen van congestie of tijdelijke storingen.
Hoe het technisch werkt
Het proces begint met een initiële wachttijd, bijvoorbeeld één seconde. Mislukt de eerste retry, dan wordt de wachttijd vermenigvuldigd met een constante factor, meestal twee. De tweede retry volgt na twee seconden, de derde na vier, de vierde na acht, enzovoort. Deze meetkundige reeks gaat door tot een maximale wachttijd of een maximaal aantal pogingen is bereikt. Op dat moment wordt het bericht gemarkeerd als permanent mislukt.
Waarom het belangrijk is voor afzenders
Met deze methode voorkom je dat een afzender onbedoeld een Denial of Service-aanval uitvoert op een ontvangende mailserver. Mislukken duizenden berichten tegelijk en proberen ze het allemaal elke tien seconden opnieuw, dan kan de resulterende verkeerspiek de ontvanger offline houden. Door de retries te spreiden behouden afzenders een betere reputatie en vergroten ze de kans dat een tijdelijke 4xx-SMTP-fout is opgelost voordat het bericht wordt gedropt.
Praktische overwegingen
Een belangrijke aanvulling op deze strategie is jitter: een kleine hoeveelheid willekeurige variatie in de wachttijd. Zonder jitter proberen meerdere requests die tegelijk mislukten het in gesynchroniseerde golven opnieuw, wat verkeerspieken veroorzaakt. Met jitter worden retries gelijkmatig over het tijdvenster verdeeld, wat de druk op de infrastructuur verder verlaagt.
Veelgemaakte implementatiefouten
Developers vergeten vaak een maximaal aantal retries of een bovengrens voor de wachttijd in te stellen. Zonder limiet kan de wachttijd oplopen tot uren of dagen, wat onaanvaardbare vertraging oplevert voor transactionele e-mails. Een andere fout is permanente 5xx-fouten behandelen alsof ze opnieuw geprobeerd kunnen worden: exponential backoff hoort alleen bij tijdelijke 4xx-fouten, zoals rate limiting of tijdelijke greylisting.
Concreet voorbeeld
Neem een transactionele e-mail die via een API wordt verstuurd. Poging 1 mislukt door een 421-fout (server bezet). Het systeem wacht 2 seconden. Poging 2 mislukt; het systeem wacht 4 seconden. Poging 3 mislukt; het systeem wacht 8 seconden. Tegen de tijd van poging 4 heeft de ontvangende server zijn wachtrij waarschijnlijk weggewerkt en wordt de e-mail geaccepteerd. SendHQ biedt gratis tools op https://sendhq.cc/tools om je e-mailinfrastructuur efficiënt te beheren.
Vragen die teams stellen
Wat is het verschil tussen vaste en exponential backoff?
Bij vaste backoff probeer je het elke X seconden opnieuw, ongeacht het aantal mislukkingen. Bij exponential backoff wordt het interval na elke mislukking groter om de belasting van de doelserver te verminderen.
Wanneer moet je stoppen met retries?
Stop met retries wanneer een permanente 5xx-fout wordt teruggegeven, het maximale aantal pogingen is bereikt of de maximale wachttijd is bereikt.
Heeft jitter invloed op de exponentiële groei?
Nee, jitter voegt een willekeurige afwijking toe aan de berekende exponentiële wachttijd, om gesynchroniseerde retrypieken bij meerdere gelijktijdige requests te voorkomen.
Primaire bronnen
- RFC 5321: Simple Mail Transfer Protocol — RFC Editor
- M3AAWG Best Common Practices — M3AAWG