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 ప్రతి విండోలో ఎన్ని requestలు చేయవచ్చో పరిమితం చేసి, మించినప్పుడు **`429 Too Many Requests`**ను తిరిగి ఇస్తుంది. ఒక బాగా-ప్రవర్తించే client తనను తాను throttle చేసుకునేలా headers ద్వారా పరిమితులను ప్రకటిస్తుంది:

```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** (అత్యంత సరళం కానీ window అంచుల వద్ద bursty). Keys సాధారణంగా API key, user, లేదా IP ప్రకారం, distributed fleet కోసం Redisలో counters తో.

## HTTP caching

రెండు పరస్పర పూరక యంత్రాంగాలు:

**1. Expiration (`Cache-Control`)** — ఒక response ఎంతసేపు fresh‌గా ఉంటుందో server చెబుతుంది, కాబట్టి 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)తో ట్యాగ్ చేస్తుంది; 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 కోసం, సంకేతం మీరు దాన్ని ఒక **సహకార ఒప్పందం**గా చూస్తారని — clientలు గోడలోకి కొట్టుకోవడం బదులు దయగా వెనక్కి తగ్గేలా `RateLimit-*` మరియు `Retry-After` headersను బహిర్గతం చేయడం — మరియు distributed deploymentలో ఒక అల్గోరిథమ్‌ను మరియు counter ఎక్కడ ఉంటుందో (Redis, ప్రతి key ప్రకారం) పేర్కొనగలరని. Caching కోసం, ప్రధాన అంతర్దృష్టి **రెండు-tier మోడల్**: expiration (`max-age`) requestను పూర్తిగా తొలగిస్తుంది, validation (`ETag`/`304`) body‌ను దాటవేయడం ద్వారా తప్పించలేని requestలను చౌకగా చేస్తుంది. ETags **optimistic concurrency** (`If-Match` → `412`) కోసం రెట్టింపు పని చేస్తాయని ప్రస్తావించడం HTTP semanticsపై లోతైన పట్టును చూపుతుంది. ఈ యంత్రాంగాలను అర్థం చేసుకునే అభ్యర్థులే నిజమైన traffic కింద వేగంగా, స్థిరంగా ఉండే APIలను నిర్మించగలవారు, ఇదే ప్రశ్న పరీక్షిస్తున్నది.

Rate limiting

HTTP caching

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు