एक REST API में rate limiting और HTTP caching कैसे काम करते हैं?

Question

IT Interview Practice · Accepted Answer

Rate limiting server को बहुत अधिक requests से बचाता है; HTTP caching उन requests के लिए काम दोहराने से बचाता है जिनका वह पहले ही उत्तर दे चुका है। दोनों HTTP में standardized हैं और दोनों बड़े पैमाने पर एक production API के लिए आवश्यक हैं।

## Rate limiting

Server सीमित करता है कि एक client प्रति window कितनी requests कर सकता है और सीमा पार होने पर **`429 Too Many Requests`** लौटाता है। यह headers के ज़रिए सीमाओं का विज्ञापन करता है ताकि एक अच्छे व्यवहार वाला client खुद को 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 को ठीक-ठीक बताता है कि कितनी देर प्रतीक्षा करनी है। आम algorithms: **token bucket** (एक bucket आकार तक bursts की अनुमति देता है, स्थिर रूप से refill होता है — सामान्य पसंद), **sliding window**, और **fixed window** (सबसे सरल पर window किनारों पर 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      ← 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 पैमाने में जीवित रहता है, इसलिए senior interviewers उनका उपयोग operational परिपक्वता जाँचने के लिए करते हैं। Rate limiting के लिए, संकेत यह है कि आप इसे एक **सहयोगी contract** मानते हैं — `RateLimit-*` और `Retry-After` headers उजागर करना ताकि clients एक दीवार में टकराने के बजाय सलीके से back off करें — और यह कि आप एक distributed deployment में एक algorithm और counter कहाँ रहता है (Redis, प्रति key) नाम ले सकते हैं। Caching के लिए, मुख्य अंतर्दृष्टि **दो-स्तरीय model** है: expiration (`max-age`) request को पूरी तरह समाप्त कर देती है, जबकि validation (`ETag`/`304`) body को छोड़कर अपरिहार्य requests को सस्ता बनाती है। यह उल्लेख करना कि ETags **optimistic concurrency** (`If-Match` → `412`) के लिए दोहरी भूमिका निभाते हैं, HTTP semantics पर गहरी पकड़ दिखाता है। जो उम्मीदवार इन तंत्रों को समझते हैं, वही हैं जो ऐसे APIs बना सकते हैं जो असली traffic के तहत तेज़ और स्थिर रहें, जो ठीक वही है जो यह सवाल परख रहा है।

Rate limiting

HTTP caching

यह क्यों महत्वपूर्ण है

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