Wie funktionieren Rate Limiting und HTTP-Caching in einer REST-API?

Question

IT Interview Practice · Accepted Answer

Rate Limiting schützt den Server vor zu vielen Requests; HTTP-Caching vermeidet die Wiederholung von Arbeit für Requests, die es bereits beantwortet hat. Beide sind in HTTP standardisiert und beide sind essenziell für eine Produktions-API bei Skalierung.

## Rate Limiting

Der Server begrenzt, wie viele Requests ein Client pro Fenster machen darf, und gibt **`429 Too Many Requests`** zurück, wenn überschritten. Er bewirbt Limits über Header, sodass ein wohlerzogener Client sich selbst drosseln kann:

```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" }
```

Der `Retry-After`-Header sagt dem Client genau, wie lange er warten soll. Gängige Algorithmen: **Token Bucket** (erlaubt Bursts bis zur Bucket-Größe, füllt stetig nach — die übliche Wahl), **Sliding Window** und **Fixed Window** (am einfachsten, aber burst-anfällig an Fenstergrenzen). Keys sind meist pro API Key, User oder IP, mit Countern in Redis für eine verteilte Flotte.

## HTTP-Caching

Zwei komplementäre Mechanismen:

**1. Expiration (`Cache-Control`)** — der Server sagt, wie lange eine Response frisch bleibt, sodass Client/CDN sie **ganz ohne Request** wiederverwenden:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / Conditional Requests)** — wenn die Frische unsicher ist, revalidiert der Client günstig. Der Server taggt eine Response mit einem **`ETag`** (einem Versions-Fingerabdruck); der Client sendet ihn in `If-None-Match` zurück, und wenn unverändert, gibt der Server **`304 Not Modified`** **ohne Body** zurück:

```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
```

ETags treiben auch **Optimistic Concurrency** an: sende `If-Match: "a1b2c3"` bei einem `PUT`, und der Server gibt `412 Precondition Failed` zurück, falls jemand anderes die Ressource zuerst geändert hat — was Lost Updates verhindert.

## Warum es wichtig ist

Zusammen sind das die Art, wie eine REST-API Skalierung übersteht, daher nutzen Senior-Interviewer sie, um operative Reife zu prüfen. Beim Rate Limiting ist das Signal, dass du es als **kooperativen Contract** behandelst — `RateLimit-*`- und `Retry-After`-Header exponierst, damit Clients elegant zurückweichen, statt gegen eine Wand zu hämmern — und dass du einen Algorithmus benennen kannst und wo der Counter lebt (Redis, pro Key) in einem verteilten Deployment. Beim Caching ist die zentrale Einsicht das **zweistufige Modell**: Expiration (`max-age`) eliminiert den Request vollständig, während Validation (`ETag`/`304`) die unvermeidbaren Requests günstig macht, indem der Body übersprungen wird. Zu erwähnen, dass ETags doppelte Arbeit für **Optimistic Concurrency** leisten (`If-Match` → `412`), zeigt eine tiefere Beherrschung der HTTP-Semantik. Kandidaten, die diese Mechanismen verstehen, sind diejenigen, die APIs bauen können, die unter echtem Traffic schnell und stabil bleiben, was genau das ist, was die Frage testet.

Rate Limiting

HTTP-Caching

Warum es wichtig ist

Ähnliche Fragen