Rate Limits და დატვირთვის კონტროლი

TL; DR

საიმედო წრე არის ლიმიტებისა და კვოტების ერთობლიობა რამდენიმე დონეზე (edge - BFF - სერვისი), რესურსების სამართლიანი განაწილება (per-tenant/გასაღები/rout), SLO ადაპტირებული trottling და backpresher ჩუმად დროის ნაცვლად. გამოიყენეთ token/leaky bucket „სიჩქარისთვის“, სააღრიცხვო კვოტების მოცურების ფანჯარა, მძიმე ოპერაციების კონკურენტული ლიმიტები, დეგრადაციის დროს დინამიური throttling და მყიფე აფსიდებისთვის circuit-breaker. ყველაფერი დაკვირვებით და პლეიბუკებით არის.

1) რატომ არის ლიმიტები iGaming/fintech

SLO და სტაბილურობა: დაცვა რეაგირების ზვავებისგან, ტურნირების მწვერვალები/ევენტები, გადახდების ზრდა.
სამართლიანობა: ერთი ტენანტი ან პარტნიორი არ „ჩამოაგდებს“ მთელ ბიუჯეტს.
ანტიაბუსი/ბოტები: ლოგინის/რეგისტრაციის, სპამის, სკრიპტის კატალოგები.
ღირებულება: ძვირადღირებული ზარების შეკავება (KYC, მოხსენებები, აგრეგაციები).
შესაბამისობა/კეთილსინდისიერი გამოყენება: კონტრაქტების ოფიციალური „სამართლიანი“ კვოტები.

2) ლიმიტების ტაქსონომია

3) ალგორითმები და სად უნდა გამოვიყენოთ

3. 1 ტოკენ ბუკეტი (ნაგულისხმევი)

პარამეტრები: 'rate' (ნიშნები/წმ), 'burst' (მაქსიმალური რეზერვი).
შესანიშნავია API read, გადახდა/სტატუსები, BFF.
ცარიელი ავზით 429 + 'Retry-After'.

3. 2 Leaky Bucket (საშუალო)

გარანტირებული „დანგრევა“ RPS, სასარგებლოა ვებჰუკებისთვის, ისე რომ არ გაიტანოთ ვორკერები.

3. 3 Fixed Window vs Sliding Window

Fixed - მარტივი, მაგრამ „საზღვრები“; Sliding - გულწრფელი ჩანაწერი ფანჯარაში (წთ/საათი/დღე).
გამოიყენეთ Sliding სახელშეკრულებო კვოტებისთვის.

3. 4 Concurrent Limits

ერთდროულად აქტიური ამოცანების ლიმიტი. იდეალურია ექსპორტისთვის/რეპორტირებისთვის, KYC პაკეტებისთვის, გადამუშავებისთვის.
დეფიციტით - 429/503 + რიგი/ნახევარი.

3. 5 Cost/Complexity Limiter

GraphQL/ძებნა: ჩვენ ვთვლით „ღირებულებას“ სიღრმეში/კარდინალობაში/გაფართოებებში.
„ძვირადღირებული“ მოთხოვნების შეწყვეტა/დეგრადაცია, მოთხოვნის პასუხი.

4) შეზღუდვის გასაღებები

per-tenant (მულტიარენდი, სამართლიანობა),

per-apapey _ key/client _ id (პარტნიორები),

per-route (კრიტიკული მუტაციები უფრო მკაცრია),

per-user/device/IP/ASN/geo (ანტიბოტი/ანტისკრიპტი),

per-BIN/ქვეყანა (გადახდის მეთოდები, ემიტენტებისა და პროვაიდერების დაცვა),

per-method (GET უფრო რბილია, POST/PUT უფრო მკაცრია).

შემადგენლობა: მთავარი გასაღები + „რისკის მულტიპლიკატორი“ (ახალი ანგარიში, TOR/მარიონეტული, მაღალი chargeback რისკი).

5) SLO ადაპტირებული trottling

• გამომწვევი: 'p95 ლატენტობა', '5xx', 'queue len', 'CPU/IO saturation'.
• მოქმედებები: შეამცირეთ rate/burst, ჩართეთ outlier-ejection, გაჭრა „ძვირადღირებული“ როუტები, დროებითი degrade (მძიმე ველების/აგრეგაციების გარეშე).
• დაბრუნება: ეტაპობრივად (25-50-100%) N სიგნალების ზედიზედ ინტერვალებით ნორმალიზებით.

6) ინტეგრაცია არქიტექტურაში

API Gateway (edge): პირველადი rate/ítas, geo/ASN, HMAC/JWT სავალდებულო, 429/' Retry-After '.
BFF/Service Mesh: თხელი per-route/per-tenant limits, concurrent-limits, circuit-breakers აფსიდებისთვის.
სერვისის შიგნით: მძიმე ოპერაციების სემფორები, ხაზების უკანა პლანზე, „სამუშაო აუზები“ ზომით.
ვებჰუკი: ცალკეული ingress endpoint leaky bucket და retray ბუფერი.

7) კონფიგურაცია (ფრაგმენტები)

yaml plugins:
- name: rate-limiting config:
policy: local minute: 600    # 10 rps limit_by: consumer fault_tolerant: true
- name: response-ratelimiting config:
limits:
heavy: { minute: 60 }

yaml circuit_breakers:
thresholds: { max_connections: 1000, max_requests: 800 }
outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s http_filters:
- name: envoy. filters. http. local_ratelimit typed_config:
token_bucket: { max_tokens: 100, tokens_per_fill: 100, fill_interval: 1s }
filter_enabled: { default_value: 100% }
filter_enforced: { default_value: 100% }

pseudo sema = Semaphore(MAX_ACTIVE_EXPORTS_PER_TENANT)
if! sema. tryAcquire(timeout=100ms) then return 429 with retry_after=rand(1..5)s process()
sema. release()

pseudo cost = sum(weight(field) cardinality(arg))
if cost > tenant. budget then reject(429,"query too expensive")

8) პოლიტიკოსები სხვადასხვა არხისთვის

REST

GET - რბილი, POST/PATCH/DELETE - უფრო მკაცრი; „idempotent“ სტატუსის/შემოწმების გადატვირთვა შესაძლებელია.
გადახდისთვის: limites 'auth/capture/refund' per-user/tenant/BIN/ქვეყანა.

GraphQL

Pepth/complexity caps, persisted/whitelisted queries, „ალიასის“ ლიმიტები.

WebSocket/SSE

სიხშირის ლიმიტი "subscribe/unsubscribe", ჩაფხუტი ტოპიკის რაოდენობისთვის, ღონისძიების ზომების მონიტორინგი და send-queue "გადატვირთვისას" policy _ disconnect ".

ვებჰუკი

მიღებაზე Leaky bucket, per-sender კვოტები, dead-letter რიგები, დეტერმინირებული 2xx/429.

9) მომხმარებელთა უკუკავშირი

• `Retry-After: `
• `X-RateLimit-Limit/Remaining/Reset`
• კვოტებისთვის - 403 კოდი '@ ta _ exceeded "და მითითება გეგმის განახლება.
• დოკუმენტაცია: limites OpenAPI/SDL + გვერდებზე „Fair Use“.

10) მონიტორინგი და დაშბორდები

• ლიმიტის ჰიტები: 'rate. limit. hit 'კლავიშებზე/როუტებზე/ტენანტებზე.
• 429/503 доля, latency p50/p95/p99, error rate, queue length, open circuits.
• Fair share: საუკეთესო მოხმარების ტენანტები, „bully detector“.
• Webhuki: მიღება/retrai, drop-rate, საშუალო lag.

• 429 არა უმეტეს მთლიანი RPS- ის 1-3% (ბოტების გარეშე).
• p95 ლიმიტის დამატება 5-10 ms edge.
• დეგრადაციის შემდეგ გამოჯანმრთელების დრო 10 წუთია.

sql
SELECT ts::date d, tenant, route,
SUM(hits) AS limit_hits,
SUM(total) AS total_calls,
SUM(hits)::decimal/NULLIF(SUM(total),0) AS hit_rate
FROM ratelimit_stats
GROUP BY 1,2,3
ORDER BY d DESC, hit_rate DESC;

11) ინციდენტების ფლეიბუკი

Retray- ის ქარიშხალი (აფსიდის ვარდნა): ჩართეთ global throttling, აამაღლეთ backoff, გახსნათ circuit-breaker, დაუბრუნეთ „სწრაფი შეცდომები“ დროის ნაცვლად.
Bot Attack/Scraping: მკაცრი cap IP/ASN/Geo, ჩართეთ WAF/JS გამოწვევა, შეზღუდეთ კატალოგები/ძებნა.
ტურნირის/ევენტურობის მწვერვალი: პრევენციულად გაზარდოს კითხვის ლიმიტები, შეამციროს „ძვირადღირებული ველები“, ჩართოთ კეში/დენორმალიზაცია.
Webhuks of PSP: დროებითი leaky bucket, კრიტიკული ტიპების პრიორიტეტი, dead-letter და retter- ის გაფართოება.

12) ტესტირება და UAT

დატვირთვა: RPS კიბე, ბუჩქები × 10 ნორმალური.
სამართლიანობა: 1 „ხარბი“ ტენანტის ემულაცია გლობალური ბიუჯეტის არაუმეტეს X% -ს შეადგენს.
დეგრადაცია: SLO ადაპტაცია ამცირებს ლიმიტებს და ინახავს p95 დერეფანში.
სასაზღვრო შემთხვევები: ფანჯრის შეცვლა (მაღარო), საათის გასწორება, Redis/sharding კლავიშების მასშტაბები.
კონტრაქტი: სათაურები 429 და Retry-After წარმოდგენილია, SDK არის სწორად დამხმარე.

13) ლიმიტის საცავი

ადგილობრივი ლიმიტების (მცირე მტევნების) მემორიალი.
Redis/Memcached განაწილებული (Lua სკრიპტები ატომურობისთვის).
ჰაშის გასაღებების შარდვა; TTL ფანჯრების ქვეშ; ქეში დაკარგვისთვის bacap მეტრიკა.
Idempotence: ლიმიტერმა არ უნდა დაარღვიოს idempotent განმეორებითი გამოწვევები (რეგისტრაცია მოთხოვნის გასაღების მიხედვით).

14) პოლიტიკური მენეჯმენტი (მთავრობა)

ლიმიტების კატალოგი: ვინ არის მფლობელი, რა გასაღებები/ბარიერი/დიეტა.
Feature flags სწრაფი კონცენტრატორებისთვის (crisis mode).
პოლიტიკოსის ვერსია და RFC პროცესი ხელშეკრულების კვოტების შეცვლისთვის.
A/B ექსპერიმენტები ოპტიმალური ბარიერების შესარჩევად.

15) ანტი შაბლონები

გლობალური ერთი ზღვარი „ყველა API- სთვის“.
მხოლოდ ფიქსირებული ფანჯრები და „ზღვარი“ გადახტომა.
უკუკავშირის გარეშე ლიმიტი (არა 'Retry-After '/headers).
ჩუმად დროა, სწრაფი 429/503 ნაცვლად.
Per-tenant fair shar- ის არარსებობა - ერთი კლიენტი დანარჩენებს აცხრობს.
არ არსებობს GraphQL/სირთულის ძებნა.
Nuli concurrent guard არის მტვერსასრუტი BD/PSP.

16) მინი-თაღლითური არჩევანი

სტანდარტულად: token bucket (rate + burst) per-tenant + route.
ფულის/ანგარიშების კვოტები: sliding window დღე/თვე.
მძიმე ოპერაციები: concurrent-limits + რიგი.
GraphQL/поиск: complexity-budgets + persisted queries.
WS/webhuks: leaky bucket + backpressure.
Кризис: dynamic throttling + circuit-breaker + degrade.

რეზიუმე

დატვირთვის კონტროლი მრავალ დონის დისციპლინაა: რეგულარული ალგორითმები (bucket/ფანჯრები/კონკურენტუნარიანობა), სამართლიანი ლიმიტის გასაღებები, SLO ადაპტაცია და გამჭვირვალე გამოხმაურება. GathQL/WS/Webhuks- ის სპეციალიზებული პოლიტიკის გამოყენებით და პლეიბუკებთან დაკვირვებით, თქვენ პიკის მოვლენებსა და სხვის გაუმართაობებს კონტროლირებად სიტუაციებად აქცევთ - საღებავების, გატეხილი გადახდების და კონვერტაციის ხარვეზების გარეშე.