एउटा REST API मा rate limiting र HTTP caching कसरी काम गर्छन्?

Question

IT Interview Practice · Accepted Answer

Rate limiting ले server लाई धेरै request बाट जोगाउँछ; HTTP caching ले पहिल्यै जवाफ दिइसकेका request का लागि काम दोहोर्‍याउन जोगाउँछ। दुवै HTTP मा standardize गरिएका छन् र दुवै ठूलो स्तरको 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 आकारसम्म 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) सँग 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
```

ETag ले **optimistic concurrency** पनि चलाउँछ: एउटा `PUT` मा `If-Match: "a1b2c3"` पठाउनुहोस्, र यदि अरू कसैले resource पहिले परिवर्तन गरे भने server ले `412 Precondition Failed` फर्काउँछ — lost update रोक्दै।

## यो किन महत्त्वपूर्ण छ

सँगै यी नै एउटा REST API ले स्तर कसरी टिकाउँछ भन्ने हुन्, त्यसैले senior interviewer हरूले तिनलाई सञ्चालन परिपक्वता जाँच्न प्रयोग गर्छन्। Rate limiting का लागि, सङ्केत भनेको तपाईंले यसलाई एउटा **सहकारी सम्झौता** मान्नुहुन्छ — `RateLimit-*` र `Retry-After` header प्रकट गरेर ताकि client हरू पर्खालमा ठोकिनुको सट्टा शालीनतापूर्वक back off गरून् — र तपाईं distributed deployment मा एउटा algorithm र counter कहाँ बस्छ (Redis, प्रति key) नाम दिन सक्नुहुन्छ। Caching का लागि, मुख्य अन्तर्दृष्टि **दुई-तह model** हो: expiration (`max-age`) ले request पूरै हटाउँछ, जबकि validation (`ETag`/`304`) ले body छोडेर अपरिहार्य request हरूलाई सस्तो बनाउँछ। ETag ले **optimistic concurrency** (`If-Match` → `412`) का लागि दोहोरो काम गर्छ भनी उल्लेख गर्नाले HTTP semantics को गहिरो पकड देखाउँछ। यी संयन्त्र बुझ्ने उम्मेदवारहरू नै वास्तविक traffic मुनि छिटो र स्थिर रहने API बनाउन सक्नेहरू हुन्, जुन ठ्याक्कै यो प्रश्नले जाँचिरहेको कुरा हो।

Rate limiting

HTTP caching

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू