Rate limiting na HTTP caching hufanyaje kazi katika REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting hulinda server dhidi ya requests nyingi mno; HTTP caching huepuka kurudia kazi kwa requests ambazo tayari imezijibu. Zote zimesawazishwa katika HTTP na zote ni muhimu kwa API ya production kwa kiwango kikubwa.

## Rate limiting

Server huweka kikomo cha requests ngapi client anaweza kufanya kwa kila dirisha na hurudisha **`429 Too Many Requests`** ikizidiwa. Hutangaza vikomo kupitia headers ili client mwenye tabia njema aweze kujidhibiti:

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

Header ya `Retry-After` humwambia client hasa muda gani wa kusubiri. Algoriti zinazozoeleka: **token bucket** (huruhusu bursts hadi ukubwa wa bucket, hujaza upya kwa utaratibu — chaguo la kawaida), **sliding window**, na **fixed window** (rahisi zaidi lakini yenye bursts kwenye kingo za dirisha). Keys kwa kawaida ni kwa kila API key, user, au IP, zikiwa na counters katika Redis kwa fleet ya distributed.

## HTTP caching

Njia mbili zinazokamilishana:

**1. Kuisha muda (`Cache-Control`)** — server husema response inakaa fresh kwa muda gani, ili client/CDN aitumie tena **bila request yoyote kabisa**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Uthibitishaji (`ETag` / conditional requests)** — wakati freshness haina uhakika, client huthibitisha upya kwa gharama nafuu. Server hutia response tagi ya **`ETag`** (alama ya vidole ya toleo); client huituma tena katika `If-None-Match`, na ikiwa haijabadilika server hurudisha **`304 Not Modified`** ikiwa **bila 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 pia huwezesha **optimistic concurrency**: tuma `If-Match: "a1b2c3"` kwenye `PUT`, na server hurudisha `412 Precondition Failed` ikiwa mtu mwingine alibadilisha rasilimali kwanza — ikizuia updates zilizopotea (lost updates).

## Kwa nini ni muhimu

Kwa pamoja hizi ndizo jinsi REST API inavyonusurika kiwango kikubwa, hivyo wahoji wa senior huzitumia kuangalia ukomavu wa kiuendeshaji. Kwa rate limiting, ishara ni kwamba unaichukulia kama **mkataba wa ushirikiano** — ukiweka wazi headers za `RateLimit-*` na `Retry-After` ili clients zirudi nyuma kwa staha badala ya kugonga ukuta — na kwamba unaweza kutaja algoriti na mahali counter inapokaa (Redis, kwa kila key) katika deployment ya distributed. Kwa caching, utambuzi muhimu ni **mfumo wa tabaka mbili**: kuisha muda (`max-age`) huondoa request kabisa, ilhali uthibitishaji (`ETag`/`304`) hufanya requests zisizoepukika kuwa nafuu kwa kuruka body. Kutaja kwamba ETags hufanya kazi maradufu kwa **optimistic concurrency** (`If-Match` → `412`) huonyesha umahiri wa kina zaidi wa semantiki za HTTP. Wagombea wanaoelewa njia hizi ndio wanaoweza kujenga APIs zinazobaki haraka na thabiti chini ya traffic halisi, ndiyo hasa kile swali linalojaribu.

Rate limiting

HTTP caching

Kwa nini ni muhimu

Maswali yanayohusiana