REST API માં rate limiting અને HTTP caching કેવી રીતે કામ કરે છે?

Question

IT Interview Practice · Accepted Answer

Rate limiting server ને બહુ બધા requests થી સુરક્ષિત કરે છે; HTTP caching પહેલેથી જવાબ આપેલા requests માટે કામ પુનરાવર્તન ટાળે છે. બંને HTTP માં પ્રમાણભૂત છે અને બંને scale પર production API માટે આવશ્યક છે.

## Rate limiting

Server એક client દર window કેટલા requests કરી શકે તે મર્યાદિત કરે છે અને વટાવાય ત્યારે **`429 Too Many Requests`** પરત કરે છે. તે headers દ્વારા મર્યાદાઓ જાહેર કરે છે જેથી સારી રીતે વર્તતો client જાતે 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 ને બરાબર કેટલી વાર રાહ જોવી તે કહે છે. સામાન્ય algorithms: **token bucket** (bucket size સુધીના bursts ને પરવાનગી આપે છે, સ્થિર રીતે refill થાય છે — સામાન્ય પસંદગી), **sliding window**, અને **fixed window** (સૌથી સરળ પણ window edges પર bursty). Keys સામાન્ય રીતે દર API key, user, કે IP પ્રમાણે હોય છે, distributed fleet માટે Redis માં counters સાથે.

## HTTP caching

બે પૂરક મિકેનિઝમ્સ:

**1. Expiration (`Cache-Control`)** — server કહે છે કે response કેટલા સમય સુધી fresh રહે છે, જેથી client/CDN તેને **કોઈ request વગર જ** ફરી વાપરે:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / conditional requests)** — જ્યારે freshness અનિશ્ચિત હોય, client સસ્તામાં revalidate કરે છે. Server response ને **`ETag`** (version fingerprint) સાથે tag કરે છે; client તેને `If-None-Match` માં પાછું મોકલે છે, અને જો ન બદલાયું હોય તો server **body વગર** **`304 Not Modified`** પરત કરે છે:

```http
GET /users/42 HTTP/1.1
If-None-Match: "a1b2c3"
```
```http
HTTP/1.1 304 Not Modified      ← ખાલી body, bandwidth બચાવે છે
```

```text
Fresh (max-age ની અંદર)     → cache માંથી served, 0 requests
Stale પણ ETag મેળ ખાય       → 304, નાનો response, ફરી render નહીં
Stale અને બદલાયું           → 200 નવા body + નવા ETag સાથે
```

ETags **optimistic concurrency** ને પણ સક્ષમ કરે છે: `PUT` પર `If-Match: "a1b2c3"` મોકલો, અને જો બીજા કોઈએ resource ને પહેલા બદલ્યો હોય તો server `412 Precondition Failed` પરત કરે છે — lost updates અટકાવે છે.

## આ શા માટે મહત્વનું છે

એકસાથે આ એ છે કે REST API scale માંથી કેવી રીતે બચે છે, તેથી senior interviewers તેમનો ઉપયોગ operational પરિપક્વતા તપાસવા કરે છે. Rate limiting માટે, સંકેત એ છે કે તમે તેને **સહકારી contract** તરીકે ગણો — `RateLimit-*` અને `Retry-After` headers ને ખુલ્લા કરીને જેથી clients દીવાલમાં અથડાવાને બદલે સૌમ્યતાથી પાછળ હટે — અને તમે distributed deployment માં algorithm અને counter ક્યાં રહે છે (Redis, દર key) તે નામ આપી શકો. Caching માટે, મુખ્ય સૂઝ છે **two-tier model**: expiration (`max-age`) request ને સંપૂર્ણપણે દૂર કરે છે, જ્યારે validation (`ETag`/`304`) અનિવાર્ય requests ને body છોડીને સસ્તા બનાવે છે. ETags **optimistic concurrency** (`If-Match` → `412`) માટે બેવડી ફરજ બજાવે છે તેનો ઉલ્લેખ HTTP semantics પર ઊંડી પકડ દર્શાવે છે. જે ઉમેદવારો આ મિકેનિઝમ્સ સમજે છે તેઓ એવા છે જે વાસ્તવિક traffic હેઠળ ઝડપી અને સ્થિર રહેતા APIs બનાવી શકે છે, જે બરાબર એ છે જે પ્રશ્ન ચકાસી રહ્યો છે.

Rate limiting

HTTP caching

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો