Rate limiting: алгоритми та реалізація

Навіщо обмежувати навантаження

Rate limiting захищає API не лише від зловмисників, а й від власних клієнтів із багом у коді, який випадково зациклюється на повторних запитах. Без лімітів один необережний інтеграційний скрипт здатен покласти сервіс не гірше за DDoS-атаку. Детальніше про суміжний підхід можна прочитати в матеріалі «GraphQL vs REST у 2026: що обрати».

Три популярні алгоритми

Token bucket — у кожного клієнта є «відро» токенів, яке поповнюється з фіксованою швидкістю; запит списує токен, а якщо їх немає — відхиляється. Алгоритм добре переносить короткочасні сплески трафіку.

Leaky bucket згладжує навантаження інакше: запити потрапляють у чергу фіксованого розміру й обробляються з постійною швидкістю, зайве просто відкидається — це ближче до рівномірного потоку, ніж до дозволу сплесків.

Sliding window рахує кількість запитів за ковзний, а не фіксований інтервал часу, уникаючи проблеми «подвійного ліміту» на межі вікон, характерної для простого fixed window.

На практиці для розподілених систем найчастіше обирають sliding window поверх Redis з атомарними операціями INCR і EXPIRE — це дає точність без складної синхронізації між інстансами сервісу. Ці ідеї перегукуються з темами «Патерн CQRS для складних доменів» та «Blue-Green і Canary деплой: різниця та коли застосовувати».