Bir REST API'de rate limiting ve HTTP caching nasıl çalışır?

Question

IT Interview Practice · Accepted Answer

Rate limiting, server'ı çok fazla istekten korur; HTTP caching, zaten yanıtladığı istekler için işi tekrarlamaktan kaçınır. Her ikisi de HTTP'de standartlaştırılmıştır ve her ikisi de ölçekli bir production API için temeldir.

## Rate limiting

Server, bir client'ın her pencere başına kaç istek yapabileceğini sınırlar ve aşıldığında **`429 Too Many Requests`** döndürür. Limitleri header'lar aracılığıyla ilan eder, böylece iyi davranan bir client kendini kısıtlayabilir (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" }
```

`Retry-After` header'ı client'a tam olarak ne kadar bekleyeceğini söyler. Yaygın algoritmalar: **token bucket** (bir bucket boyutuna kadar burst'e izin verir, sürekli yeniden doldurur — olağan tercih), **sliding window** ve **fixed window** (en basiti ama pencere kenarlarında burst'lü). Anahtarlar genellikle API key, user ya da IP başınadır; dağıtık bir filo için sayaçlar Redis'te tutulur.

## HTTP caching

Birbirini tamamlayan iki mekanizma:

**1. Son kullanma (`Cache-Control`)** — server bir response'un ne kadar süre taze kalacağını söyler, böylece client/CDN onu **hiç istek yapmadan** yeniden kullanır:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Doğrulama (`ETag` / conditional request)** — tazelik belirsiz olduğunda, client ucuza yeniden doğrular. Server bir response'u bir **`ETag`** ile etiketler (bir sürüm parmak izi); client onu `If-None-Match`'te geri gönderir ve değişmemişse server **body olmadan** **`304 Not Modified`** döndürür:

```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'ler ayrıca **optimistic concurrency**'ye güç verir: bir `PUT`'ta `If-Match: "a1b2c3"` gönderin ve başka biri resource'u önce değiştirdiyse server `412 Precondition Failed` döndürür — kayıp güncellemeleri (lost update) önler.

## Neden önemli

Bir arada bunlar, bir REST API'nin ölçeğe nasıl dayandığıdır, bu yüzden senior mülakatçılar operasyonel olgunluğu kontrol etmek için bunları kullanır. Rate limiting için sinyal, onu bir **işbirlikçi sözleşme** olarak ele almanız — client'lar bir duvara toslamak yerine zarifçe geri çekilsin diye `RateLimit-*` ve `Retry-After` header'larını açığa çıkarmanız — ve dağıtık bir dağıtımda bir algoritma ile sayacın nerede yaşadığını (Redis, key başına) adlandırabilmenizdir. Caching için temel içgörü **iki katmanlı modeldir**: son kullanma (`max-age`) isteği tamamen ortadan kaldırır, doğrulama (`ETag`/`304`) ise kaçınılmaz istekleri body'yi atlayarak ucuzlatır. ETag'lerin **optimistic concurrency** için (`If-Match` → `412`) çifte görev yaptığını anmak, HTTP semantiğine daha derin hâkimiyet gösterir. Bu mekanizmaları anlayan adaylar, gerçek trafik altında hızlı ve kararlı kalan API'ler kurabilenlerdir, ki soru tam olarak bunu test eder.

Rate limiting

HTTP caching

Neden önemli

İlgili sorular