Jitter bij herhaalpogingen

Retry jitter voegt willekeur toe aan de wachttijd vóór een nieuwe aanroep. Het spreidt pogingen van meerdere clients in de tijd. Dat is vooral nuttig als veel clients dezelfde storing tegelijk opmerken: een gelijke pauze kan de volgende belastingspiek alleen maar uitstellen.

Drie clients, verschillende wachttijden

In een fictief voorbeeld mogen drie clients elk een willekeurige wachttijd binnen een venster van 0–2 s kiezen vóór hun volgende poging. Ze wachten bijvoorbeeld 0.4 s, 1.1 s en 1.7 s. Deze waarden verduidelijken de spreiding; het is geen aanbevolen configuratie. Ook met jitter kunnen pogingen samenvallen.

De retrystrategie bepaalt nog steeds welke fouten een nieuwe poging rechtvaardigen, hoeveel pogingen zijn toegestaan en wanneer de totale tijdslimiet is bereikt. De aanwijzingen van het doelsysteem over wachttijden moeten worden gevolgd. Bij exponentiële backoff groeit het wachtbereik doorgaans met volgende pogingen tot een ingestelde bovengrens; jitter varieert de werkelijke pauze volgens de gebruikte regel.

Willekeur maakt het herhalen van een bewerking niet veilig. Een verloren antwoord kan een al voltooide schrijfbewerking verbergen. Vóór een nieuwe poging heeft de integratie daarom een veilige herhaalregel nodig, zoals idempotentie of controle van het resultaat.

Bronnen

• AWS Builders’ Library: Timeouts, retries, and backoff with jitter

• AWS Architecture Blog: Exponential Backoff And Jitter