REST API에서 rate limiting과 HTTP caching은 어떻게 동작하는가?

Question

IT Interview Practice · Accepted Answer

rate limiting은 너무 많은 request로부터 server를 보호하고, HTTP caching은 이미 답한 request에 대해 작업을 반복하지 않게 한다. 둘 다 HTTP에서 표준화되어 있으며 둘 다 대규모 production API에 필수다.

## rate limiting

server는 client가 창(window)마다 할 수 있는 request 수를 제한하고, 초과 시 **`429 Too Many Requests`**를 반환한다. 잘 처신하는 client가 스스로 조절할 수 있도록 헤더로 한도를 알린다:

```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` 헤더는 client에게 정확히 얼마나 기다려야 하는지 알려 준다. 흔한 알고리즘: **token bucket**(버킷 크기까지 burst를 허용하고 꾸준히 리필 — 통상적 선택), **sliding window**, **fixed window**(가장 단순하나 창 경계에서 burst 발생). key는 보통 API key, user, 또는 IP 단위이며, 분산 플릿을 위해 카운터를 Redis에 둔다.

## HTTP caching

서로 보완하는 두 메커니즘:

**1. 만료(`Cache-Control`)** — server가 response가 얼마나 오래 fresh한지 말하므로, client/CDN이 **request를 전혀 하지 않고** 재사용한다:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. 검증(`ETag` / conditional request)** — freshness가 불확실할 때 client가 저렴하게 재검증한다. server는 response에 **`ETag`**(버전 지문)를 태그하고, client는 그것을 `If-None-Match`로 되돌려 보내며, 변경이 없으면 server는 **body 없이** **`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**에도 힘을 준다: `PUT`에 `If-Match: "a1b2c3"`를 보내면, 다른 누군가가 먼저 리소스를 바꿨을 때 server가 `412 Precondition Failed`를 반환한다 — 잃어버린 갱신(lost update)을 막는다.

## 왜 중요한가

이 둘은 함께 REST API가 규모를 견디는 방식이므로, senior 면접관은 이를 통해 운영 성숙도를 확인한다. rate limiting에서 신호는 당신이 그것을 **협력적 계약**으로 다루는지다 — `RateLimit-*`와 `Retry-After` 헤더를 노출해 client가 벽에 부딪히는 대신 우아하게 물러나게 하는 것 — 그리고 분산 배포에서 알고리즘과 카운터가 사는 곳(Redis, key 단위)을 댈 수 있는지다. caching에서 핵심 통찰은 **2단 모델**이다: 만료(`max-age`)는 request를 통째로 없애고, 검증(`ETag`/`304`)은 피할 수 없는 request를 body를 건너뛰어 저렴하게 만든다. ETag가 **optimistic concurrency**(`If-Match` → `412`)로 이중 임무를 한다는 것을 언급하면 HTTP 시맨틱에 대한 더 깊은 이해를 보여 준다. 이 메커니즘을 이해하는 지원자가 실제 트래픽 아래에서 빠르고 안정적으로 유지되는 API를 만들 수 있는 사람이며, 그것이 바로 이 질문이 시험하는 것이다.

rate limiting

HTTP caching

왜 중요한가

관련 질문