Systemy dodają losowe opóźnienie do retry właśnie po to, żeby działały bardziej przewidywalnie
Exponential backoff wydłuża przerwy między kolejnymi próbami, ale sam nie wystarcza, jeśli tysiące klientów zaczęło retry w tej samej chwili. Wszyscy mogą czekać 1 sekundę, potem 2, potem 4 — i za każdym razem ponownie uderzać w serwer jednocześnie. Jitter dodaje losową składową do opóźnienia, rozpraszając klientów w czasie. Google SRE zaleca randomized exponential backoff, a AWS podkreśla jitter jako sposób uniknięcia zsynchronizowanych fal. Kontrolowany chaos na poziomie pojedynczych klientów tworzy bardziej równomierne i stabilne zachowanie całej populacji.
Backoff zmniejsza średnią częstotliwość prób
Po pierwszym błędzie klient czeka krótko, po drugim dłużej, potem jeszcze dłużej. Dzięki temu nie atakuje przeciążonego serwera w ciasnej pętli. To podstawowy exponential backoff.
Synchronizacja klientów może jednak pozostać
Jeżeli milion urządzeń straci połączenie z usługą w tej samej sekundzie i wszystkie używają identycznego algorytmu, ich harmonogram retry jest prawie taki sam. Wspólna przyczyna awarii zsynchronizowała populację. Powstają okresowe piki ruchu.
Jitter rozbija fazę
Zamiast czekać zawsze dokładnie dwie sekundy, klient losuje opóźnienie z określonego zakresu. Inny klient losuje inną wartość. Łącznie próby rozkładają się szerzej w czasie. AWS opisuje Full Jitter i inne strategie właśnie jako sposób na desynchronizację konkurujących klientów.
Losowość redukuje zjawisko emergentne
Pojedynczy klient działa mniej przewidywalnie, ale cały system działa bardziej przewidywalnie, bo nie ma ogromnych synchronicznych fal. Podobną ideę spotyka się w sieciach komputerowych i algorytmach wyboru lidera: przypadek pomaga rozbić niebezpieczną symetrię.
Jitter nie zastępuje limitów
Nadal trzeba ograniczać liczbę retry i rozpoznawać błędy, których ponawianie nie naprawi. Randomizacja jest jednym z elementów pakietu ochronnego razem z backoffem, timeoutami i retry budget. Właściwym celem nie jest „spróbować za wszelką cenę”, lecz dać systemowi czas na odzyskanie stabilności.
Jitter działa także przy wygasaniu cache'y i okresowych zadaniach
Ta sama zasada desynchronizacji ma zastosowanie poza retry. Jeśli tysiące wpisów cache wygasa w tej samej sekundzie albo tysiące workerów wykonuje zadanie co pełną minutę, system dostaje sztuczny pik. Dodanie niewielkiego losowego przesunięcia rozkłada pracę w czasie bez zmiany średniej ilości pracy. Randomizacja jest więc uniwersalnym narzędziem przeciw zjawiskom stadnym.
Pełna synchronizacja jest ukrytym wspólnym punktem awarii
Nawet gdy klienci nie dzielą serwera ani stanu, mogą dzielić identyczny harmonogram. Awaria o 12:00 synchronizuje ich retry, wspólny TTL synchronizuje odświeżenia, a cron o pełnej godzinie synchronizuje joby. Jitter usuwa ten rodzaj korelacji. Projektowanie odporności polega więc nie tylko na rozdzielaniu maszyn, ale również na rozdzielaniu momentów, w których podejmują tę samą akcję.
Dobór rozkładu jittera też ma znaczenie. Można losować pełny zakres opóźnienia, część zakresu albo stosować bardziej złożone strategie zależne od poprzedniej próby. Cel pozostaje ten sam: nie pozwolić dużej populacji klientów poruszać się w fazie. Najważniejsza nie jest konkretna formuła, lecz uznanie, że korelacja czasowa sama w sobie jest ryzykiem systemowym. Losowość jest tu narzędziem redukcji korelacji.
Jitter jest szczególnie skuteczny, gdy liczba klientów jest ogromna. Pojedyncze losowanie niewiele zmienia, ale statystycznie milion niezależnych losowań rozkłada obciążenie znacznie równiej niż milion identycznych timerów. To przykład zjawiska, w którym lokalna niedeterministyczność tworzy globalną regularność. Podobne idee wykorzystuje się w protokołach dostępu do medium i rozproszonych algorytmach wyborczych. W dużej skali właśnie takie drobne przesunięcia potrafią zdecydować, czy ruch wygląda jak płaska fala, czy seria niszczących pików. To prosta technika, ale w dużych flotach ma bardzo realny wpływ na stabilność.