ஒரு REST API-இல் rate limiting மற்றும் HTTP caching எப்படி வேலை செய்கின்றன?

Question

IT Interview Practice · Accepted Answer

Rate limiting server-ஐ அதிக requests-இலிருந்து பாதுகாக்கிறது; HTTP caching ஏற்கனவே பதிலளித்த requests-க்கு வேலையை மீண்டும் செய்வதைத் தவிர்க்கிறது. இரண்டும் HTTP-இல் standardize செய்யப்பட்டவை, மேலும் இரண்டும் scale-இல் ஒரு production API-க்கு அத்தியாவசியம்.

## Rate limiting

Server ஒரு client ஒவ்வொரு window-க்கும் எத்தனை requests செய்யலாம் என்பதை வரம்பிட்டு, மீறும்போது **`429 Too Many Requests`**-ஐத் திருப்புகிறது. நன்கு நடந்துகொள்ளும் ஒரு client தானாக throttle செய்யும்படி headers வழியாக limits-ஐ அறிவிக்கிறது:

```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 size வரை bursts-ஐ அனுமதிக்கிறது, சீராக refill ஆகிறது — வழக்கமான தேர்வு), **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)-உடன் 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 scale-ஐத் தாண்டி உயிர்பிழைக்கும் வழி, எனவே senior interviewers operational முதிர்ச்சியைச் சரிபார்க்க அவற்றைப் பயன்படுத்துகிறார்கள். Rate limiting-க்கு, சமிக்ஞை நீங்கள் அதை ஒரு **கூட்டுறவு contract**-ஆகக் கருதுவது — clients ஒரு சுவரில் மோதுவதற்குப் பதிலாக அழகாக back off செய்யும்படி `RateLimit-*` மற்றும் `Retry-After` headers-ஐ வெளிப்படுத்துதல் — மேலும் ஒரு distributed deployment-இல் ஒரு algorithm மற்றும் counter எங்கே இருக்கிறது (Redis, ஒவ்வொரு key வாரியாக) என்பதைப் பெயரிட முடிதல். Caching-க்கு, முக்கிய நுண்ணறிவு **இரு-அடுக்கு model**: expiration (`max-age`) request-ஐ முழுவதுமாக நீக்குகிறது, அதேசமயம் validation (`ETag`/`304`) body-ஐத் தவிர்ப்பதன் மூலம் தவிர்க்க முடியாத requests-ஐ மலிவாக்குகிறது. ETags **optimistic concurrency**-க்கு (`If-Match` → `412`) இரட்டைப் பணி செய்கின்றன என்பதைக் குறிப்பிடுவது HTTP semantics மீது ஆழமான கட்டுப்பாட்டைக் காட்டுகிறது. இந்த வழிமுறைகளைப் புரிந்துகொள்ளும் candidates தான் உண்மையான traffic-இன் கீழ் வேகமாகவும் நிலையாகவும் இருக்கும் APIs-ஐக் கட்ட முடிபவர்கள், அதுதான் இந்தக் கேள்வி சரியாகச் சோதிக்கிறது.

Rate limiting

HTTP caching

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்