Как работают rate limiting и HTTP-кэширование в REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting защищает сервер от слишком большого числа запросов; HTTP-кэширование избегает повторения работы для запросов, на которые уже был дан ответ. Оба стандартизированы в HTTP и оба необходимы для production API на масштабе.

## Rate limiting

Сервер ограничивает, сколько запросов клиент может сделать за окно, и возвращает **`429 Too Many Requests`** при превышении. Он объявляет лимиты через заголовки, чтобы благовоспитанный клиент мог сам себя притормаживать:

```http
HTTP/1.1 200 OK
RateLimit-Limit: 100
RateLimit-Remaining: 12
RateLimit-Reset: 30
```

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 30

{ "error": "rate limit exceeded, retry in 30s" }
```

Заголовок `Retry-After` сообщает клиенту, сколько именно ждать. Распространённые алгоритмы: **token bucket** (допускает всплески до размера бакета, пополняется равномерно — обычный выбор), **sliding window** и **fixed window** (проще всего, но всплески на границах окна). Ключами обычно служат API-ключ, пользователь или IP, со счётчиками в Redis для распределённого парка.

## HTTP caching

Два дополняющих друг друга механизма:

**1. Истечение (`Cache-Control`)** — сервер говорит, как долго ответ остаётся свежим, чтобы клиент/CDN переиспользовали его **вообще без запроса**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Валидация (`ETag` / conditional requests)** — когда свежесть неясна, клиент дёшево перепроверяет. Сервер помечает ответ **`ETag`** (отпечаток версии); клиент отправляет его обратно в `If-None-Match`, и если не изменилось, сервер возвращает **`304 Not Modified`** **без тела**:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← empty body, saves bandwidth
```

```text
Fresh (within max-age)   → served from cache, 0 requests
Stale but ETag matches   → 304, tiny response, no re-render
Stale and changed        → 200 with new body + new ETag
```

ETag также обеспечивают **оптимистичную конкурентность (optimistic concurrency)**: отправьте `If-Match: "a1b2c3"` в `PUT`, и сервер вернёт `412 Precondition Failed`, если кто-то другой изменил ресурс первым — предотвращая потерянные обновления.

## Почему это важно

Вместе это то, как REST API переживает масштаб, поэтому senior-интервьюеры используют их для проверки операционной зрелости. Для rate limiting сигнал — что вы относитесь к нему как к **кооперативному контракту** — предоставляя заголовки `RateLimit-*` и `Retry-After`, чтобы клиенты изящно отступали, а не долбились в стену — и что вы можете назвать алгоритм и где живёт счётчик (Redis, по каждому ключу) в распределённом развёртывании. Для кэширования ключевое озарение — **двухуровневая модель**: истечение (`max-age`) полностью устраняет запрос, а валидация (`ETag`/`304`) делает неизбежные запросы дешёвыми, пропуская тело. Упоминание того, что ETag выполняют двойную роль для **оптимистичной конкурентности** (`If-Match` → `412`), показывает более глубокое владение семантикой HTTP. Кандидаты, понимающие эти механизмы, — это те, кто может строить API, остающиеся быстрыми и стабильными под реальным трафиком, а именно это вопрос и проверяет.

Rate limiting

HTTP caching

Почему это важно

Похожие вопросы