Throttling vs Rate Limiting — ключ до стабільних API-флоу. Коли ліміт, наприклад 100 запитів за хвилину, перевищено, ви ризикуєте отримати 429 Too Many Requests і зупинку процесу. Вихід — керувати темпом і повторними спробами. Використовуйте Retry-After, експоненційний backoff та jitter, щоб рознести повтори і уникати колективних піків. Нижче — як зробити це в n8n без зайвого коду.
Що таке throttling та rate limiting?
Throttling і rate limiting — це підходи до контролю API-трафіку. Rate limiting встановлює межу запитів у періоді й може повертати 429 при перевищенні. Throttling натомість сповільнює або ставить запити в чергу, зменшуючи потік замість миттєвих відмов.
Обидва методи реалізує провайдер API. Ваш контроль — це реакція флоу: вирівнювати темп наперед і відступати, коли сервіс просить зачекати. В n8n це означає батчинг, паузи, обмеження паралельності та грамотно налаштовані повтори.
Як наслідок, різниця для вас — це помилка проти затримки. При rate limiting ви бачите 429 і вирішуєте, коли повторити. При throttling запит може потрапити у чергу й виконатися пізніше без помилки, але з відтермінуванням наступних кроків.
Як працюють throttling і rate limiting?
Алгоритм ліміту впливає на темп. Фіксоване вікно може дозволяти 100 запитів за хвилину із скиданням лічильника. Ковзне вікно рахує попередні 60 секунд. Token bucket дає «сплески», а leaky bucket згладжує черги до сталого потоку.
За фіксованим вікном легко потрапити у «межові» сплески між хвилинами. Ковзне вікно уникає жорсткого ресету, тож очікування кінця хвилини не завжди повертає повний бюджет запитів відразу.
Token bucket поповнює «жетони» рівномірно; невикористані накопичуються, дозволяючи короткі сплески. Leaky bucket працює навпаки: запити стають у чергу і виходять з контрольованою швидкістю.
Ваш висновок? Підбирайте патерн темпу під конкретний API, читаючи документацію до лімітів. Те, що стабільно працює зі «сталом», може ловити 429 на «ковзному» чи навпаки.
Які стратегії обробки API-лімітів?
Якщо є Retry-After, дотримуйтесь його замість гадати. Якщо ні — застосуйте експоненційний backoff: наприклад 1 секунда, потім 2 секунди, далі 4 секунди і 8 секунд. Додайте jitter, щоб рознести спільні повтори в часі.
Встановіть верхню межу затримки і кількість спроб, щоб не крутити нескінченні ретраї. Якщо API каже «зачекай» через Retry-After, це має пріоритет над внутрішнім графіком повторів вашого флоу.
Коли перевищено ліміт, ви отримаєте 429 Too Many Requests. Повтор одразу відтворює проблему. Backoff руйнує цей цикл, даючи сервісу «видихнути» й повернутися в робочий стан.
Як запустити exponential backoff в n8n?
У n8n ви керуєте профілактикою і відновленням без коду. Для профілактики використайте HTTP Request з Items per Batch та Batch Interval — це контролює, скільки запитів і як часто виходить з вузла.
Потрібен точніший темп? Поєднайте Loop Over Items з Wait, щоб ставити паузи між кожним викликом під конкретний ліміт або ковзне вікно 60 секунд.
Для відновлення після відмов вмикайте Retry On Fail і налаштовуйте Wait Between Tries під експоненційний backoff: 1 → 2 → 4 → 8 секунд. Так ви не штурмуєте API одразу після 429.
Коли всі спроби вичерпані, маршрут збоїв відправте до окремого процесу через Error Trigger для логування, сповіщень або альтернативних шляхів відновлення.
Як n8n допомагає керувати шаблонами запитів?
n8n — платформа автоматизації з відкритим кодом, орієнтована на AI. Вона дозволяє темпувати запити наперед, повторювати їх після 429 і спрямовувати стійкі помилки в інші флоу. Додавайте обмеження паралельності, щоб кілька флоу разом не перевантажували один і той самий API.
Для API з прогнозованими лімітами профілактика краща за відновлення. Почніть з темпу та батчинг-контролю, а повтори і помилкообробку тримайте як «страхувальну сітку» на випадок піків.
| Параметр | Throttling | Rate limiting | Приклад backoff |
|---|---|---|---|
| Що відбувається при піку | Затримка/черга queue | Відмова 429 reject | — |
| Типова межа | Сповільнення потоку | 100 запитів за хвилину (приклад) | — |
| Орієнтир вікна | — | 60 seconds (ковзне/фіксоване) | — |
| Підказка провайдера | — | Retry-After у відповіді | — |
| Графік повторів | — | — | 1 / 2 / 4 / 8 секунд |
Часті питання
Throttling vs rate limiting порівняння?
Rate limiting жорстко обмежує кількість викликів за період і при перевищенні повертає 429 Too Many Requests. Throttling зменшує швидкість або ставить запити у чергу замість негайної відмови. Для ваших флоу це означає різні реакції: або ретраї з backoff, або очікування завершення відкладених викликів без помилок.
Скільки коштує n8n rate limiting (pricing)?
Цей матеріал не містить відомостей про вартість. Він фокусується на тому, як у n8n темпувати виклики (батчинг, інтервали), використовувати Retry On Fail з експоненційним backoff та Error Trigger для відновлення після стійких 429. За деталями щодо тарифів зверніться до офіційних ресурсів n8n.
n8n throttling для engineering команд — для кого підходить?
Підхід підходить командам інженерії, які працюють з API-інтеграціями, агентами або agentic workflows. Ви можете обмежувати паралельність, налаштовувати батчинг і паузи, а також керувати повторними спробами — усе в рамках флоу. Це стабілізує інтеграції під фіксовані межі або ковзні вікна 60 секунд.
Як працюють Retry-After і експоненційний backoff у практиці?
Коли API повертає 429 із заголовком Retry-After, дочекайтесь вказаного часу, а потім застосуйте експоненційний backoff. При відсутності заголовка використовуйте послідовність 1, 2, 4, 8 секунд із jitter. Встановіть межу спроб і маршрутизуйте збої через Error Trigger для логування та оповіщення.
На основі матеріалу n8n Official Blog.
