API
Rate limiting: тест на свободное припоминание
Припоминание бьёт перечитывание. На каждый промпт скажи или напиши полный ответ по памяти, прежде чем открыть модельный — усилие припоминания и закрепляет компромиссы, когда ты проектируешь лимитер под давлением.
Реконструируй спину юнита — граничный всплеск, компромиссы алгоритмов, ловушку распределённого счётчика, атомарность и контракт 429 — не подглядывая в урок.
- 01Почему fixed window протекает 2x всплеском и как sliding window log и token bucket каждый его убирают?
- 02Сравни sliding window log и sliding window counter. Когда что выбирать?
- 03Объясни, как token bucket держит средний rate, всё же разрешая всплески, и что контролирует параметр capacity.
- 04In-memory лимитер проходит все тесты на ноутбуке, но в production пропускает трафик сильно выше лимита. Объясни сбой и фикс.
- 05Почему запускать проверку rate-limit в Redis единым Lua-скриптом, а не INCR, затем EXPIRE?
- 06Что контракт 429 должен дисциплинированному клиенту и почему RateLimit-Reset должен быть delta-seconds, а не UNIX timestamp?
Если ты смог реконструировать каждый ответ по памяти, ты держишь спину юнита: fixed window протекает 2x граничным всплеском, который sliding window и token bucket убирают по-разному; log точен, но тяжёл по памяти, а counter аппроксимирует его за два integer; token bucket держит среднее, а capacity задаёт всплеск; пер-нодовый счётчик — ложь за балансировщиком; общий счётчик в Redis надо обновлять атомарно через Lua; а контракт 429 должен клиенту Retry-After в delta-seconds плюс jitter, чтобы избежать thundering herd.