How do rate limiting and HTTP caching work in a REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting protects the server from too many requests; HTTP caching avoids repeating work for requests it has already answered. Both are standardized in HTTP and both are essential for a production API at scale.

## Rate limiting

The server caps how many requests a client may make per window and returns **`429 Too Many Requests`** when exceeded. It advertises limits via headers so a well-behaved client can self-throttle:

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

The `Retry-After` header tells the client exactly how long to wait. Common algorithms: **token bucket** (allows bursts up to a bucket size, refills steadily — the usual choice), **sliding window**, and **fixed window** (simplest but bursty at window edges). Keys are usually per API key, user, or IP, with counters in Redis for a distributed fleet.

## HTTP caching

Two complementary mechanisms:

**1. Expiration (`Cache-Control`)** — the server says how long a response stays fresh, so the client/CDN reuses it with **no request at all**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / conditional requests)** — when freshness is uncertain, the client revalidates cheaply. The server tags a response with an **`ETag`** (a version fingerprint); the client sends it back in `If-None-Match`, and if unchanged the server returns **`304 Not Modified`** with **no body**:

```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 also power **optimistic concurrency**: send `If-Match: "a1b2c3"` on a `PUT`, and the server returns `412 Precondition Failed` if someone else changed the resource first — preventing lost updates.

## Why it matters

Together these are how a REST API survives scale, so senior interviewers use them to check operational maturity. For rate limiting, the signal is that you treat it as a **cooperative contract** — exposing `RateLimit-*` and `Retry-After` headers so clients back off gracefully rather than hammering into a wall — and that you can name an algorithm and where the counter lives (Redis, per key) in a distributed deployment. For caching, the key insight is the **two-tier model**: expiration (`max-age`) eliminates the request entirely, while validation (`ETag`/`304`) makes the unavoidable requests cheap by skipping the body. Mentioning that ETags do double duty for **optimistic concurrency** (`If-Match` → `412`) shows deeper command of HTTP semantics. Candidates who understand these mechanisms are the ones who can build APIs that stay fast and stable under real traffic, which is exactly what the question is testing.

Rate limiting

HTTP caching

Why it matters

Related questions