Rate limiting на собеседовании системного аналитика

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Зачем rate limiting

Защита от:

  • DDoS / abuse.
  • Accidental traffic spikes (badly programmed client).
  • Resource fairness между tenants.
  • Cost control (expensive operations).

Без rate limiting — один user может consumate all capacity.

Token bucket

Bucket holds N tokens. Каждое request consumes 1 token. Tokens refill rate R / sec.

capacity = 100 tokens
refill_rate = 10 tokens/sec

t=0:   bucket = 100
t=1s:  request → bucket = 99 + 10 (refill) = 100
       request × 100 → bucket = 0
t=10s: bucket back to 100

Pros: allows burst (up to capacity), smooths over time.

Cons: complex implementation.

Standard в API gateways.

Leaky bucket

Requests добавляются в queue (bucket). Drain at constant rate.

Если bucket full → reject incoming.

Pros: smooth output, no bursts allowed.

Cons: holds requests in memory, latency added.

Менее common, чем token bucket.

Fixed window

Counter per (user, time_window). Reset each window.

window: 1 minute
limit: 100 requests

User A:
  12:00:00-12:00:59: 100 requests OK, 101st rejected.
  12:01:00: counter resets.

Pros: simple.

Cons: burst at window boundary (200 requests в 2 seconds — 100 в 12:00:59 + 100 в 12:01:00).

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Sliding window

Sliding window log. Store timestamp каждого request. Count в last N seconds.

Pros: accurate.

Cons: memory expensive (timestamp per request).

Sliding window counter. Approximation. Combine current + previous window.

weight = (60 - elapsed_in_current_window) / 60
estimated_count = current + previous × weight

Compromise — accuracy и memory.

HTTP responses

429 Too Many Requests.

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1715040000

Retry-After — когда client может retry.

X-RateLimit-* headers — informative для well-behaved clients.

Связанные темы

FAQ

Это официальная информация?

Нет. Статья основана на классических работах rate limiting и индустриальной практике.


Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.