У розробці розподілених систем помилки - це не виняток, а норма. Мережа може підвиснути, сервіс - тимчасово впасти, база - відмовити на секунду. І в цей момент постає просте, але небезпечне питання: як саме повторювати запит? Якщо робити це так само, система легко сама себе доб’є.
Саме тут з’являються експоненційна затримка (exponential backoff) і випадковий джитер (random jitter).
Exponential Backoff
Exponential Backoff - це стратегія повторних спроб, коли кожен наступний retry (повторна спроба) відбувається з дедалі більшою затримкою. Ідея дуже проста: якщо щось зламалось, не варто одразу ж знову стукати в ті самі двері. Перший повтор може бути майже миттєвим, другий - через секунду, третій - через дві, потім чотири, вісім і так далі. Затримка росте експоненційно.
Це дає системі час "перевести подих". Якщо сервіс тимчасово перевантажений або падає через пікове навантаження, exponential backoff зменшує тиск, а не посилює його. Без цієї стратегії клієнти починають масово робити retry одночасно, і навіть здоровий сервіс може не витримати такого шквалу.
Але тут є підступний момент. Уявіть собі тисячу клієнтів, які одночасно отримали помилку і використовують однакову формулу backoff. Вони всі чекатимуть одну секунду, потім дві, потім чотири - і знову разом вдарять по серверу. Виходить синхронізований натовп, який приходить хвилями. Це вже знайома проблема - ефект "thundering herd".
Саме тому до exponential backoff майже завжди додають випадковий джитер (random jitter). Джитер - це невеликий випадковий зсув у затримці. Замість того щоб чекати рівно 4 секунди, клієнт може почекати 3.2, інший - 4.7, ще хтось - 2.9. Усі ті ж експоненційні затримки зберігаються, але запити більше не приходять одночасно.
З джитером система починає поводитися "живіше" і стабільніше. Навантаження розмазується в часі, сервісу легше відновитися, а ймовірність повторного падіння через масові retry різко зменшується. Це особливо важливо для API, черг, job-воркерів і будь-яких інтеграцій із зовнішніми сервісами.
У підсумку exponential backoff відповідає на питання "коли повторювати?", а джитер - "як зробити це не синхронно з усіма іншими?" Разом вони формують базову архітектуру для надійних систем. Якщо у вас є retry без backoff - це червоний прапорець. Якщо є backoff без джитера - жовтий. А коли є обидва, система має значно більше шансів пережити реальні, а не лабораторні збої.
