ਇੱਕ 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 ਹਰ 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 ਦੇ ਆਕਾਰ ਤੱਕ 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 ਇੰਟਰਵਿਊ ਲੈਣ ਵਾਲੇ ਇਹਨਾਂ ਨੂੰ ਸੰਚਾਲਨ ਪਰਿਪੱਕਤਾ ਜਾਂਚਣ ਲਈ ਵਰਤਦੇ ਹਨ। Rate limiting ਲਈ, ਸੰਕੇਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ **ਸਹਿਯੋਗੀ ਇਕਰਾਰ** ਵਜੋਂ ਮੰਨਦੇ ਹੋ — `RateLimit-*` ਅਤੇ `Retry-After` headers ਪੇਸ਼ ਕਰਦੇ ਹੋਏ ਤਾਂ ਜੋ clients ਇੱਕ ਕੰਧ ਵਿੱਚ ਵੱਜਣ ਦੀ ਬਜਾਏ ਸ਼ਾਲੀਨਤਾ ਨਾਲ ਪਿੱਛੇ ਹਟਣ — ਅਤੇ ਤੁਸੀਂ ਇੱਕ distributed deployment ਵਿੱਚ ਇੱਕ algorithm ਅਤੇ counter ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ (Redis, ਹਰ key ਅਨੁਸਾਰ) ਦਾ ਨਾਮ ਲੈ ਸਕਦੇ ਹੋ। Caching ਲਈ, ਮੁੱਖ ਸੂਝ **ਦੋ-ਪੱਧਰੀ ਮਾਡਲ** ਹੈ: expiration (`max-age`) request ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖ਼ਤਮ ਕਰ ਦਿੰਦੀ ਹੈ, ਜਦਕਿ validation (`ETag`/`304`) ਅਟੱਲ requests ਨੂੰ body ਛੱਡ ਕੇ ਸਸਤਾ ਬਣਾ ਦਿੰਦੀ ਹੈ। ਇਹ ਜ਼ਿਕਰ ਕਰਨਾ ਕਿ ETags **optimistic concurrency** (`If-Match` → `412`) ਲਈ ਦੋਹਰੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੇ ਹਨ, HTTP semantics 'ਤੇ ਡੂੰਘੀ ਪਕੜ ਦਰਸਾਉਂਦਾ ਹੈ। ਜੋ ਉਮੀਦਵਾਰ ਇਹ ਵਿਧੀਆਂ ਸਮਝਦੇ ਹਨ, ਉਹੀ ਉਹ ਹਨ ਜੋ ਅਜਿਹੇ APIs ਬਣਾ ਸਕਦੇ ਹਨ ਜੋ ਅਸਲੀ traffic ਹੇਠ ਤੇਜ਼ ਅਤੇ ਸਥਿਰ ਰਹਿੰਦੇ ਹਨ, ਬਿਲਕੁਲ ਉਹੀ ਜੋ ਇਹ ਸਵਾਲ ਜਾਂਚ ਰਿਹਾ ਹੈ।

Rate limiting

HTTP caching

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ