API
Rate limiting: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту rate limiting — компромиссы алгоритмов, граничный всплеск, распределённые счётчики, атомарность и контракт 429.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение по дизайну, которое ты принимаешь под реальным трафиком — не определение для заучивания, а компромисс, который надо взвесить, когда клиент долбит твою границу сразу через шесть нод.
Цель
Убедись, что связываешь выбор алгоритма, поведение всплесков, ловушку распределённого счётчика, атомарность и контракт 429 — тот синтез, к которому вёл урок.
Викторина
Completed
Лимит 100/мин на fixed window с ключом {key}:{minute}. Сколько запросов клиент в худшем случае легально уложит в промежуток ~1 секунда и почему?
Heads-up Одно окно ограничено 100, но у лимитера нет памяти через границу сброса. Клиент заполняет конец одной минуты и начало следующей, поэтому у границы оказывается до 2x.
Heads-up Fixed window ничего не усредняет. Каждое окно независимо выдаёт полные 100, поэтому худший случай на шве — 2x, а не 1.5x.
Heads-up Ограничивает: худший случай строго равен 2x лимита, сконцентрированных у границы. Эта известная утечка — повод тянуться к sliding window или token bucket, а не доказательство отсутствия лимита.
Викторина
Completed
Публичный API обслуживает бёрстовых браузерных клиентов — загрузка страницы выстреливает ~12 запросов разом, затем простой. Нужен честный средний rate, терпящий эти бёрсты загрузки. Какой алгоритм подходит лучше?
Heads-up Leaky bucket сглаживает выход до устойчивого rate, чем активно отказывает легитимному бёрсту загрузки и добавляет очередную задержку. Он для хрупкого downstream, а не для дружелюбия к бёрстовым клиентам.
Heads-up Дёшево, но он протекает 2x граничным всплеском и не моделирует бёрсты намеренно — любая терпимость случайна, зависит от того, куда запрос попал в окне, а не настраиваемая ручка.
Heads-up Точный, но для высокообъёмного бёрстового трафика память на ключ в один timestamp на запрос — тяжёлая цена за точность, которая тут не нужна. Прибереги его для audit-grade счёта.
Викторина
Completed
In-memory лимитер проходит все тесты на ноутбуке, но в production трафик идёт сильно выше настроенных 100/мин. За балансировщиком четыре app-ноды. Корневая причина?
Heads-up Длина TTL не умножает лимит на число нод. Дефект в том, что счётчик пер-процессный; лимит должен жить в хранилище, общем для всех нод.
Heads-up Конфиг верен на каждой ноде; баг архитектурный. N in-memory счётчиков тихо суммируются в N раз больше настроенного лимита независимо от значения.
Heads-up Sticky sessions замаскировали бы баг, привязав клиента к одной ноде, но это хрупко и ломает честность. Реальный фикс — общий счётчик в Redis, а не привязка сессий.
Викторина
Completed
Ты переносишь счётчик в Redis и реализуешь как INCR, затем EXPIRE. Почему единый Lua-скрипт — более надёжный паттерн?
Heads-up Скорость ни при чём — INCR и так sub-millisecond. Причина — атомарность: скрипт исключает interleaving и гонку с ключом без TTL.
Heads-up Lua-скрипты выполняются в памяти, как любая команда Redis; персистентность ортогональна. Выгода — атомарный цикл read-decide-update.
Heads-up Redis и так выполняет команды однопоточно; именно поэтому скрипт исполняется без interleaving других команд. Lua использует это свойство, а не меняет его.
Викторина
Completed
Сервис аутентификации должен держать точный пер-аккаунт лимит ради compliance — без граничного зазора, каждая попытка учтена. Какой алгоритм и какую цену ты принимаешь?
Heads-up Для грубого edge-лимита ~0.003% ошибки прекрасно, но это всё ещё аппроксимация. Audit-grade точный счёт ради compliance — единственный случай, где ты платишь за log.
Heads-up Fixed window точен внутри окна, но протекает до 2x у границы, поэтому скользящий счёт не точен. Этот зазор недопустим для аудируемого лимита.
Heads-up Token bucket намеренно разрешает ограниченный всплеск выше устойчивого rate, поэтому не держит точный скользящий счёт. Он оптимизирует под дружелюбие, а не под audit-grade точность.
Викторина
Completed
На fixed window ты отклоняешь с 429 и жёстким Retry-After 30 секунд. На следующей границе окна error rate снова взлетает. Что произошло и какой фикс?
Heads-up Истечение ключей ожидаемо и корректно; оно не вызывает синхронный всплеск повторов. Всплеск — от выдачи всем клиентам одинакового дедлайна Retry-After.
Heads-up Сокращение лишь сдвигает синхронную волну раньше — все клиенты всё равно повторяют вместе. Фикс — десинхронизировать их jitter'ом и непрерывно пополняемой моделью, а не меньшей фиксированной задержкой.
Heads-up Здесь клиенты дисциплинированы — они подчинились Retry-After, именно поэтому проснулись разом. Herd самонанесён одинаковым дедлайном, а не плохим поведением клиентов.
Итог
Сквозная линия: то, как запросы попадают в окна, — это где fixed window протекает 2x граничным всплеском; sliding window log покупает точность памятью на запрос, sliding counter аппроксимирует её за два integer, а token bucket моделирует всплески как настраиваемый capacity. Ничего из этого не реально, если счётчик живёт в пер-нодовой памяти — раздели его в Redis, сделай read-decide-update атомарным через Lua, а отклоняя — соблюдай контракт: 429 + Retry-After в delta-seconds плюс jitter, чтобы граница сброса не стала thundering herd.