Наш открытый API набирает обороты быстрее, чем мы успеваем масштабировать серверы, и часть интеграторов постоянно заваливает эндпоинты пиковыми сериями запросов, отчего тормозят все остальные. Нам требуется специалист, который соберёт отдельную службу лимитирования и квот перед API и будет применять адекватные ограничения для каждого ключа доступа. Подчеркну: речь не про API-шлюз и не про приёмник вебхуков — задача узкая и конкретная, это именно ограничение скорости и подсчёт квот. Нужны гибкие правила на уровне ключа: бесплатный ключ получает, условно, шестьдесят обращений в минуту, платный — несколько тысяч, а само срабатывание лимитов остаётся прогнозируемым, быстрым и не проседает на всплесках.
Из алгоритмов хотелось бы иметь и модель ведра токенов для сглаживания коротких пиков, и оконный счётчик со скользящим окном для честного подсчёта внутри интервала, причём выбор задаётся в настройках правила. Все счётчики держим в Redis, чтобы несколько экземпляров API опирались на единую картину расхода без рассинхрона, и чтобы проверка стоила буквально миллисекунду-другую. Кроме базовых порогов нужны настоящие тарифные уровни с суточными и месячными объёмами, фиксация фактического потребления по каждому ключу и возможность отдавать клиенту остаток доступного лимита. Если порог пробит, служба возвращает код 429, проставляет привычные заголовки с лимитом, остатком и временем сброса и добавляет Retry-After, чтобы вежливые клиенты сами притормаживали.
От вас ждём компактную панель администрирования или удобный формат конфигурации для описания тарифов и назначения ключей, хранилище показателей под биллинг и аналитику и внятную документацию. Опишите, пожалуйста, подход к атомарным операциям в Redis, защиту от состояний гонки при большой параллельности и план нагрузочного тестирования ограничителя до запуска в продакшн.
— Правила на ключ с моделями ведра токенов и скользящего окна
— Тарифные уровни с суточными и месячными объёмами
— Единые счётчики в Redis с минимальной добавленной задержкой
— Фиксация расхода и отчётность под биллинг
— Правильные ответы 429 с заголовками лимита, остатка, сброса и Retry-After
— Панель настройки тарифов и ключей, документация и нагрузочные тесты
Из алгоритмов хотелось бы иметь и модель ведра токенов для сглаживания коротких пиков, и оконный счётчик со скользящим окном для честного подсчёта внутри интервала, причём выбор задаётся в настройках правила. Все счётчики держим в Redis, чтобы несколько экземпляров API опирались на единую картину расхода без рассинхрона, и чтобы проверка стоила буквально миллисекунду-другую. Кроме базовых порогов нужны настоящие тарифные уровни с суточными и месячными объёмами, фиксация фактического потребления по каждому ключу и возможность отдавать клиенту остаток доступного лимита. Если порог пробит, служба возвращает код 429, проставляет привычные заголовки с лимитом, остатком и временем сброса и добавляет Retry-After, чтобы вежливые клиенты сами притормаживали.
От вас ждём компактную панель администрирования или удобный формат конфигурации для описания тарифов и назначения ключей, хранилище показателей под биллинг и аналитику и внятную документацию. Опишите, пожалуйста, подход к атомарным операциям в Redis, защиту от состояний гонки при большой параллельности и план нагрузочного тестирования ограничителя до запуска в продакшн.
— Правила на ключ с моделями ведра токенов и скользящего окна
— Тарифные уровни с суточными и месячными объёмами
— Единые счётчики в Redis с минимальной добавленной задержкой
— Фиксация расхода и отчётность под биллинг
— Правильные ответы 429 с заголовками лимита, остатка, сброса и Retry-After
— Панель настройки тарифов и ключей, документация и нагрузочные тесты
