Зазначимо: коли API-ключ надсилає 10 000 запитів за секунду на ендпоінт /order, без системи рейт-лімітингу бекенд лягає за хвилину. Ми проєктуємо та впроваджуємо захист, який відсікає аномальний трафік, зберігаючи чуйність для легітимних користувачів. На відміну від готових шлюзів, наше рішення враховує специфіку криптобірж: різні ліміти для maker/taker, WebSocket-з'єднання та bursts на основі балансу. На реальному проєкті з піковим навантаженням 50k RPS ми зменшили кількість відхилених легітимних запитів у 3 рази порівняно зі стандартним Nginx limit_req. В основі — комбінація token bucket та sliding window log на Redis Cluster. Перший допускає короткочасні сплески, другий забезпечує точний облік у ковзному вікні.
Чому рейт-лімітинг критичний для crypto exchange?
API криптобіржі — ласий шматок для ботів та скриптів. Без рейт-лімітингу зловмисник може:
- Запустити DDoS одним ключем, утилізуючи всі 10 Гбіт/с каналу
- Спарсити всі ордери за секунди (data scraping) — до 100 000 запитів на хвилину
- Покласти ендпоінт /order надмірною кількістю запитів, викликаючи timeout у легітимних трейдерів
Ми стикалися з кейсами, коли high-frequency трейдери випадково надсилали 5000 запитів на секунду на /balance, кладучи matching engine. Наша система відсікає такі аномалії без втручання людини, з latency не більше 2 мс.
Який алгоритм обрати для надійного rate limiting?
Token bucket дає гнучкість: налаштовуєте швидкість наповнення (наприклад, 100 токенів/с) та розмір bucket (burst до 500 токенів) — сплески в 5 разів вище середнього ліміту проходять без блокування. Sliding window log точніший: він рахує запити в ковзному вікні і не дає перевищити ліміт ні на секунду. Комбінуємо обидва: token bucket для більшості ендпоінтів, sliding window для критичних (наприклад, /withdraw). Це дає кращий захист і мінімум false positives — у 3 рази менше, ніж у стандартного limit_req.
Коли використовувати token bucket, а коли sliding window?
Token bucket підходить для згладжування bursts з можливістю накопичення — ідеально для публічних ендпоінтів (ticker, kline). Sliding window log обов'язковий для операцій з грошима (withdraw, transfer), де точність обліку критична. Ми обираємо алгоритм на основі профілю кожного маршруту.Що входить в роботу з рейт-лімітингу?
Ми передаємо повний комплект deliverables:
- Документація з архітектури та правил
- Доступ до дашбордів Grafana (логи, метрики, алерти)
- Навчання команди експлуатації (2-3 сесії)
- Підтримка на етапі впровадження 2 тижні
Як ми проєктуємо систему рейт-лімітингу
Архітектура та стек — розробка системи рейт
| Компонент | Технологія |
|---|---|
| Сховище лічильників | Redis Cluster (6 нод, реплікація) |
| Алгоритми | Token bucket, Sliding window log |
| Проксі | Nginx (limit_req_zone) + OpenResty Lua |
| Бекенд | Go middleware на основі hash map + Redis |
| Моніторинг | Prometheus + Grafana (panels для кожного правила) |
Приклад конфігурації Nginx
http { limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s; server { location /api/v1/ticker { limit_req zone=api burst=50 nodelay; proxy_pass http://backend:8080; } } } LUA-скрипт для Redis (token bucket)
local key = KEYS[1] local rate = tonumber(ARGV[1]) local capacity = tonumber(ARGV[2]) local now = redis.call('TIME')[1] local bucket = redis.call('HGETALL', key) local tokens = bucket[1] and tonumber(bucket[1]) or capacity local lastRefill = bucket[2] and tonumber(bucket[2]) or now local tokensToAdd = (now - lastRefill) * rate / 1000 if tokensToAdd > 0 then tokens = math.min(capacity, tokens + tokensToAdd) lastRefill = now end if tokens >= 1 then tokens = tokens - 1 redis.call('HMSET', key, tokens, lastRefill) redis.call('EXPIRE', key, 10) return 1 else return 0 end Реалізація ґрунтується на офіційному прикладі з документації Redis — Token Bucket Lua script. Для WebSocket-з'єднань налаштовуємо окремий token bucket з ключем по user_id та обмеженням 10 повідомлень на секунду. Використовуємо Redis Pub/Sub для синхронізації між нодами.
Переваги кастомного рішення перед готовими шлюзами
Готові шлюзи на кшталт Kong або AWS API Gateway не підтримують кастомні ліміти на WebSocket, відмінність прав для maker/taker, або механізм burst на основі балансу. Наше рішення зроблено під біржу: ви самі задаєте tier користувача (VIP отримує 1000 r/s, звичайний — 10), налаштовуєте логіку для кожного ендпоінту та інтегруєте з вашою системою білінгу або скорингу.
Покрокова реалізація: від аналізу до моніторингу
- Аналіз профілю навантаження. Збираємо логи за місяць, визначаємо розподіл запитів по ендпоінтах, пікові години, типові аномалії.
- Проєктування правил. Розробляємо tier-сітку, ліміти на кожен маршрут, винятки для WebSocket.
- Реалізація middleware. Пишемо на Go або Lua в Nginx — додаємо хендлер, який перевіряє ліміт перед передачею запиту на бекенд.
- Інтеграція з Redis. Налаштовуємо кластер, TTL для ключів, конвеєри для зниження latency.
- Навантажувальне тестування. Проганяємо wrk та k6 до 100k RPS, переконуємося, що rate limiter не стає вузьким місцем.
- Дашборди та алерти. У Grafana візуалізуємо: кількість відхилених запитів, ключі-порушники, використання ресурсів Redis. Налаштовуємо алерти на перевищення порогів.
- Документація та навчання. Передаємо команді інструкцію з експлуатації: як додавати правила, відключати блокування вручну, аналізувати логи.
Орієнтовні терміни
| Етап | Час |
|---|---|
| Аналіз та проєктування | 1–2 тижні |
| Розробка middleware на Go | 2–3 тижні |
| Інтеграція з Redis та налаштування кластера | 1 тиждень |
| Навантажувальне тестування | 1–2 тижні |
| Моніторинг та документація | 1 тиждень |
Повна реалізація під ключ: від 5 до 8 тижнів залежно від складності API.
Як ми гарантуємо стабільність?
Ми займаємося бекенд-розробкою криптобірж більше 5 років. За цей час реалізували системи рейт-лімітингу для проєктів з добовою аудиторією >1 млн користувачів та піковим навантаженням >50k RPS. Гарантуємо, що ваша система пройде аудит безпеки та витримає будь-які навантаження в рамках узгоджених пропускних здатностей. Середня економія на інфраструктурі за рахунок оптимізації досягає 30%.
Зв'яжіться з нами для безкоштовної консультації — ми оцінимо вашу архітектуру та запропонуємо оптимальну схему рейт-лімітингу. Замовте аудит поточної системи до кінця місяця та отримайте знижку 10%.