როგორ მუშაობს rate limiting და HTTP caching REST API-ში?

Question

IT Interview Practice · Accepted Answer

Rate limiting იცავს server-ს მეტისმეტად ბევრი request-ისგან; HTTP caching თავს არიდებს სამუშაოს გამეორებას იმ request-ებისთვის, რომლებზეც უკვე უპასუხა. ორივე სტანდარტიზებულია HTTP-ში და ორივე აუცილებელია მასშტაბზე production API-ისთვის.

## Rate limiting

server ზღუდავს, რამდენი request-ის გაკეთება შეუძლია client-ს თითო ფანჯარაზე და აბრუნებს **`429 Too Many Requests`**-ს გადაჭარბებისას. ის აცხადებს ლიმიტებს header-ების მეშვეობით, რომ კეთილგანწყობილმა client-მა შეძლოს თვით-დარეგულირება:

```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** (უშვებს burst-ებს bucket-ის ზომამდე, სტაბილურად ავსებს — ჩვეულებრივი არჩევანი), **sliding window**, და **fixed window** (ყველაზე მარტივი, მაგრამ burst-იანი ფანჯრის კიდეებზე). key-ები ჩვეულებრივ თითო API key-ზე, user-ზე ან IP-ზეა, მთვლელებით Redis-ში განაწილებული ფლოტისთვის.

## HTTP caching

ორი ურთიერთშემავსებელი მექანიზმი:

**1. Expiration (`Cache-Control`)** — server ამბობს, რამდენ ხანს რჩება response ახალი, ასე რომ client/CDN მას **request-ის გარეშე** ხელახლა იყენებს:
```http
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
```

**2. Validation (`ETag` / conditional request-ები)** — როცა სიახლე გაურკვეველია, client იაფად ხელახლა ამოწმებს. server response-ს **`ETag`**-ით მონიშნავს (ვერსიის თითის ანაბეჭდი); client მას `If-None-Match`-ში აბრუნებს, და თუ არ შეცვლილა, server აბრუნებს **`304 Not Modified`**-ს **body-ის გარეშე**:

```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-ს**: გააგზავნეთ `If-Match: "a1b2c3"` `PUT`-ზე, და server აბრუნებს `412 Precondition Failed`-ს, თუ ვინმემ სხვამ resource ადრე შეცვალა — რაც ხელს უშლის დაკარგულ განახლებებს.

## რატომ არის ეს მნიშვნელოვანი

ერთად ეს არის ის, თუ როგორ გადაურჩება REST API მასშტაბს, ამიტომ senior ინტერვიუერები მათ იყენებენ საოპერაციო სიმწიფის შესამოწმებლად. rate limiting-ისთვის სიგნალი არის ის, რომ თქვენ მას **კოოპერაციულ კონტრაქტად** ეპყრობით — ავლენთ `RateLimit-*` და `Retry-After` header-ებს, რომ client-ებმა თავაზიანად უკან დაიხიონ და არა კედელს დაეხეთქონ — და ასახელებთ ალგორითმს და მთვლელის ადგილს (Redis, თითო key-ზე) განაწილებულ დანერგვაში. caching-ისთვის მთავარი აზრი არის **ორ-დონიანი მოდელი**: expiration (`max-age`) მთლიანად აღმოფხვრის request-ს, ხოლო validation (`ETag`/`304`) გარდაუვალ request-ებს იაფად აქცევს body-ის გამოტოვებით. იმის ხსენება, რომ ETag-ები ორმაგ საქმეს აკეთებენ **optimistic concurrency-სთვის** (`If-Match` → `412`) აჩვენებს HTTP-ის სემანტიკის უფრო ღრმა ფლობას. კანდიდატები, რომლებსაც ესმით ეს მექანიზმები, არიან ისინი, ვისაც შეუძლიათ ააშენონ API-ები, რომლებიც სწრაფი და სტაბილური რჩება რეალური traffic-ის ქვეშ, რაც სწორედ ის არის, რასაც კითხვა ამოწმებს.

Rate limiting

HTTP caching

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები