REST API मध्ये rate limiting आणि HTTP caching कसे कार्य करतात?

Question

IT Interview Practice · Accepted Answer

Rate limiting server ला खूप जास्त requests पासून वाचवते; HTTP caching आधीच उत्तर दिलेल्या requests साठी काम पुन्हा करणे टाळते. दोन्ही HTTP मध्ये प्रमाणित आहेत आणि दोन्ही मोठ्या प्रमाणातील production API साठी अत्यावश्यक आहेत.

## Rate limiting

Server प्रति window एक client किती 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 आकारापर्यंत bursts ला परवानगी, स्थिरपणे पुन्हा भरतो — नेहमीची निवड), **sliding window**, आणि **fixed window** (सर्वात साधे पण window कडांना bursty). Keys सहसा प्रति API key, user, किंवा IP असतात, distributed fleet साठी counters Redis मध्ये.

## HTTP caching

दोन पूरक यंत्रणा:

**1. Expiration (`Cache-Control`)** — server response किती वेळ ताजे राहते ते सांगतो, त्यामुळे client/CDN ते **कोणत्याही request शिवाय** पुन्हा वापरते:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / conditional requests)** — ताजेपणा अनिश्चित असताना, 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      ← 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 **optimistic concurrency** लादेखील सक्षम करतात: एका `PUT` वर `If-Match: "a1b2c3"` पाठवा, आणि दुसऱ्याने आधी resource बदलले असल्यास server `412 Precondition Failed` परत करतो — lost updates टाळते.

## हे का महत्त्वाचे आहे

एकत्रितपणे, हे असे मार्ग आहेत ज्यांनी एक REST API scale ला तगते, म्हणून senior interviewers त्यांचा वापर operational परिपक्वता तपासण्यासाठी करतात. Rate limiting साठी, signal म्हणजे तुम्ही ते एका **सहकारी करार** म्हणून वागवता — `RateLimit-*` आणि `Retry-After` headers उघड करून जेणेकरून clients भिंतीवर आदळण्याऐवजी सौम्यपणे मागे हटतात — आणि तुम्ही एक algorithm व distributed deployment मध्ये counter कुठे राहतो (Redis, प्रति key) याचे नाव घेऊ शकता. Caching साठी, मुख्य अंतर्दृष्टी म्हणजे **दोन-स्तरीय मॉडेल**: expiration (`max-age`) request पूर्णपणे नाहीसा करते, तर validation (`ETag`/`304`) अटळ requests body वगळून स्वस्त करते. ETags **optimistic concurrency** साठी (`If-Match` → `412`) दुहेरी काम करतात हे नमूद करणे HTTP semantics वरील अधिक खोल प्रभुत्व दर्शवते. या यंत्रणा समजणारे उमेदवारच खऱ्या traffic खाली वेगवान आणि स्थिर राहणाऱ्या APIs बांधू शकतात, आणि प्रश्न नेमके तेच तपासत आहे.

Rate limiting

HTTP caching

हे का महत्त्वाचे आहे

संबंधित प्रश्न