Разработка системы рейт-лимитинга API биржи

Отметим: когда 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.

Что входит в работу по рейт-лимитингу?

Мы передаём полный комплект deliverables:

• Документация по архитектуре и правилам
• Доступ к дашбордам Grafana (логи, метрики, алерты)
• Обучение команды эксплуатации (2-3 сессии)
• Поддержка на этапе внедрения 2 недели

Как мы проектируем систему рейт-лимитинга

Архитектура и стек — разработка системы рейт

Пример конфигурации 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), настраиваете логику для каждого эндпоинта и интегрируете с вашей системой биллинга или скоринга.

Пошаговая реализация: от анализа до мониторинга

1. Анализ профиля нагрузки. Собираем логи за месяц, определяем распределение запросов по эндпоинтам, пиковые часы, типичные аномалии.
2. Проектирование правил. Разрабатываем tier-сетку, лимиты на каждый маршрут, исключения для WebSocket.
3. Реализация middleware. Пишем на Go или Lua в Nginx — добавляем хендлер, который проверяет лимит перед передачей запроса на бэкенд.
4. Интеграция с Redis. Настраиваем кластер, TTL для ключей, конвейеры для снижения latency.
5. Нагрузочное тестирование. Прогоняем wrk и k6 до 100k RPS, убеждаемся, что rate limiter не становится узким местом.
6. Дашборды и алерты. В Grafana визуализируем: количество отклонённых запросов, ключи-нарушители, использование ресурсов Redis. Настраиваем алерты на превышение порогов.
7. Документация и обучение. Передаём команде инструкцию по эксплуатации: как добавлять правила, отключать блокировки вручную, анализировать логи.

Ориентировочные сроки

Полная реализация под ключ: от 5 до 8 недель в зависимости от сложности API.

Как мы гарантируем стабильность?

Мы занимаемся бэкенд-разработкой криптобирж больше 5 лет. За это время реализовали системы рейт-лимитинга для проектов с суточной аудиторией >1 млн пользователей и пиковой нагрузкой >50k RPS. Гарантируем, что ваша система пройдёт аудит безопасности и выдержит любые нагрузки в рамках согласованных пропускных способностей. Средняя экономия на инфраструктуре за счёт оптимизации достигает 30%.

Свяжитесь с нами для бесплатной консультации — мы оценим вашу архитектуру и предложим оптимальную схему рейт-лимитинга. Закажите аудит текущей системы до конца месяца и получите скидку 10%.