Yaya rate limiting da HTTP caching ke aiki a cikin REST API?

Question

IT Interview Practice · Accepted Answer

Rate limiting yana kare server daga requests da yawa; HTTP caching yana gujewa maimaita aiki ga requests da ya riga ya amsa. Duka an tsara su a HTTP kuma duka suna da muhimmanci ga API na production a manyan sikeli.

## Rate limiting

Server yana iyakance yawan requests da client zai iya yi a kowace taga kuma yana mayar da **`429 Too Many Requests`** idan an wuce. Yana talla iyakoki ta headers don client mai kyawun hali ya iya sarrafa kansa:

```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 na `Retry-After` yana gaya wa client daidai tsawon lokacin da zai jira. Algorithms na kowa: **token bucket** (yana ba da damar bursts har zuwa girman bucket, yana sake cikawa a hankali — zaɓin da aka saba), **sliding window**, da **fixed window** (mafi sauƙi amma mai burst a gefunan taga). Keys yawanci ga kowane API key, user, ko IP, tare da counters a Redis ga rundunar da aka rarraba.

## HTTP caching

Hanyoyi biyu masu cikawa juna:

**1. Ƙarewa (`Cache-Control`)** — server yana cewa tsawon lokacin da response zai kasance sabo, don haka client/CDN yana sake amfani da shi **ba tare da request ko kaɗan ba**:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Tabbatarwa (`ETag` / conditional requests)** — sa'ad da sabon-zama ba tabbatacce ba, client yana sake tabbatarwa a arha. Server yana yiwa response tag da **`ETag`** (yatsan yatsa na version); client yana aika shi baya a `If-None-Match`, kuma idan bai canza ba server yana mayar da **`304 Not Modified`** **ba tare da body ba**:

```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 suna kuma ƙarfafa **optimistic concurrency**: aika `If-Match: "a1b2c3"` a kan `PUT`, kuma server yana mayar da `412 Precondition Failed` idan wani ya canza resource da farko — yana hana asarar sabuntawa (lost updates).

## Me ya sa yake da muhimmanci

Tare, waɗannan su ne yadda REST API ke tsira daga sikeli, don haka masu hira na senior suna amfani da su don duba balagar aiki. Ga rate limiting, siginar ita ce ka ɗauke shi a matsayin **yarjejeniya ta haɗin kai** — bayyana headers na `RateLimit-*` da `Retry-After` don clients su ja da baya cikin ladabi maimakon bugun bango — kuma za ka iya ambaton algorithm da inda counter ke zama (Redis, ga kowane key) a tura da aka rarraba. Ga caching, babbar fahimta ita ce **samfurin mataki-biyu**: ƙarewa (`max-age`) yana kawar da request gaba ɗaya, yayin da tabbatarwa (`ETag`/`304`) ke sa requests da ba za a iya gujewa su zama arha ta hanyar tsallake body. Ambaton cewa ETags suna yin aiki biyu ga **optimistic concurrency** (`If-Match` → `412`) yana nuna zurfin fahimtar ma'anonin HTTP. 'Yan takara da suka fahimci waɗannan hanyoyi su ne waɗanda za su iya gina APIs da ke ci gaba da sauri kuma tsayayye a ƙarƙashin traffic na gaske, wanda shi ne ainihin abin da tambayar ke gwadawa.

Rate limiting

HTTP caching

Me ya sa yake da muhimmanci

Tambayoyi masu alaƙa