کسی 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 یہ حد مقرر کرتا ہے کہ ایک client فی کھڑکی کتنی requests کر سکتا ہے اور حد سے تجاوز پر **`429 Too Many Requests`** واپس کرتا ہے۔ یہ headers کے ذریعے حدود کا اعلان کرتا ہے تاکہ ایک اچھے رویے والا client خود کو محدود کر سکے:

```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 کو ٹھیک بتاتا ہے کہ کتنی دیر انتظار کرنا ہے۔ عام الگورتھمز: **token bucket** (ایک bucket سائز تک bursts کی اجازت دیتا ہے، مستقل طور پر دوبارہ بھرتا ہے — معمول کا انتخاب)، **sliding window**، اور **fixed window** (سب سے سادہ مگر کھڑکی کے کناروں پر burst والا)۔ Keys عام طور پر فی API key، user، یا IP ہوتی ہیں، ایک distributed fleet کے لیے Redis میں counters کے ساتھ۔

## 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 سستے میں دوبارہ توثیق کرتا ہے۔ server ایک response کو ایک **`ETag`** (ایک version fingerprint) سے ٹیگ کرتا ہے؛ client اسے `If-None-Match` میں واپس بھیجتا ہے، اور اگر غیر تبدیل شدہ ہو تو server **`304 Not Modified`** **بغیر 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 **optimistic concurrency** کو بھی طاقت دیتے ہیں: کسی `PUT` پر `If-Match: "a1b2c3"` بھیجیں، اور اگر کسی اور نے resource پہلے بدل دیا تو server `412 Precondition Failed` واپس کرتا ہے — کھوئی ہوئی updates کو روکتے ہوئے۔

## یہ کیوں اہم ہے

مل کر یہ وہ طریقہ ہے جس سے ایک REST API پیمانے میں زندہ رہتی ہے، اس لیے senior انٹرویو لینے والے انہیں آپریشنل پختگی جانچنے کے لیے استعمال کرتے ہیں۔ rate limiting کے لیے، اشارہ یہ ہے کہ آپ اسے ایک **باہمی تعاون کے معاہدے** کے طور پر لیتے ہیں — `RateLimit-*` اور `Retry-After` headers ظاہر کرنا تاکہ clients دیوار سے ٹکرانے کے بجائے احسن انداز میں پیچھے ہٹیں — اور آپ ایک distributed deployment میں کسی الگورتھم اور counter کہاں رہتا ہے (Redis، فی key) کا نام لے سکتے ہیں۔ caching کے لیے، کلیدی بصیرت **دو سطحی ماڈل** ہے: expiration (`max-age`) request کو مکمل طور پر ختم کر دیتا ہے، جبکہ validation (`ETag`/`304`) ناگزیر requests کو body چھوڑ کر سستا بنا دیتا ہے۔ یہ ذکر کرنا کہ ETags **optimistic concurrency** (`If-Match` → `412`) کے لیے دوہرا کردار ادا کرتے ہیں HTTP کے معانی پر گہری گرفت ظاہر کرتا ہے۔ جو امیدوار ان طریقوں کو سمجھتے ہیں وہی ایسی APIs بنا سکتے ہیں جو حقیقی traffic کے تحت تیز اور مستحکم رہیں، بالکل وہی جسے یہ سوال جانچ رہا ہے۔

Rate limiting

HTTP caching

یہ کیوں اہم ہے

متعلقہ سوالات