একটি REST API-তে rate limiting আর HTTP caching কীভাবে কাজ করে?

Question

IT Interview Practice · Accepted Answer

Rate limiting server-কে অতিরিক্ত request থেকে রক্ষা করে; HTTP caching ইতিমধ্যে উত্তর দেওয়া request-এর জন্য কাজ পুনরাবৃত্তি এড়ায়। দুটিই HTTP-তে standardized এবং দুটিই বড় মাপে একটি production API-র জন্য অপরিহার্য।

## Rate limiting

Server সীমাবদ্ধ করে একটি client প্রতি window-তে কতগুলো request করতে পারে এবং অতিক্রম করলে **`429 Too Many Requests`** ফেরত দেয়। এটি header-এর মাধ্যমে সীমা বিজ্ঞাপন করে যাতে একটি সুশৃঙ্খল 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-কে ঠিক কতক্ষণ অপেক্ষা করতে হবে তা বলে। সাধারণ algorithm: **token bucket** (একটি bucket size পর্যন্ত burst-এর অনুমতি দেয়, স্থিরভাবে refill করে — সাধারণ পছন্দ), **sliding window**, আর **fixed window** (সবচেয়ে সরল কিন্তু window-এর প্রান্তে bursty)। Key সাধারণত প্রতি API key, user, বা IP অনুযায়ী, একটি distributed fleet-এর জন্য Redis-এ counter সহ।

## 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 request)** — যখন freshness অনিশ্চিত, client সস্তায় revalidate করে। Server একটি response-কে একটি **`ETag`** দিয়ে ট্যাগ করে (একটি version fingerprint); 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
```

ETag **optimistic concurrency**-ও চালায়: একটি `PUT`-এ `If-Match: "a1b2c3"` পাঠান, এবং কেউ আগে resource-টি পরিবর্তন করলে server `412 Precondition Failed` ফেরত দেয় — lost update প্রতিরোধ করে।

## এটি কেন গুরুত্বপূর্ণ

একসাথে এগুলো হলো কীভাবে একটি REST API মাপ থেকে বাঁচে, তাই senior interviewer-রা operational পরিপক্বতা যাচাই করতে এগুলো ব্যবহার করেন। Rate limiting-এর জন্য, সংকেত হলো আপনি এটিকে একটি **সহযোগিতামূলক contract** হিসেবে দেখেন — `RateLimit-*` আর `Retry-After` header উন্মুক্ত করে যাতে client দেয়ালে আঘাত করার বদলে সুন্দরভাবে পিছিয়ে যায় — এবং আপনি একটি distributed deployment-এ একটি algorithm আর counter কোথায় থাকে (Redis, প্রতি key) তা নাম দিতে পারেন। Caching-এর জন্য, মূল অন্তর্দৃষ্টি হলো **দুই-স্তরের মডেল**: expiration (`max-age`) request পুরোপুরি নির্মূল করে, আর validation (`ETag`/`304`) body এড়িয়ে অনিবার্য request-গুলোকে সস্তা করে। উল্লেখ করা যে ETag **optimistic concurrency** (`If-Match` → `412`)-এর জন্যও দ্বৈত দায়িত্ব পালন করে HTTP semantics-এর গভীরতর দখল দেখায়। যে candidate-রা এই কৌশলগুলো বোঝে তারাই এমন API বানাতে পারে যা বাস্তব traffic-এর নিচে দ্রুত ও স্থিতিশীল থাকে, ঠিক যা এই প্রশ্ন পরীক্ষা করছে।

Rate limiting

HTTP caching

এটি কেন গুরুত্বপূর্ণ

সম্পর্কিত প্রশ্ন