Throttling Pattern — tizimga keladigan request, task yoki data oqimini belgilangan tezlik va capacity doirasida cheklash yondashuvi. Throttling service’ni overload, adolatsiz foydalanish, xarajat oshishi va dependency limitlaridan himoya qiladi.
Throttling requestni rad etishi, kechiktirishi, queue’ga qo‘yishi yoki pastroq sifatli xizmatga o‘tkazishi mumkin.
Rate va concurrency
Ikki asosiy cheklov farqlanadi:
- rate limit — vaqt birligidagi request soni;
- concurrency limit — bir vaqtda bajarilayotgan operation soni.
100 request/soniya limiti har request 10 soniya davom etsa katta concurrency yaratishi mumkin.
Shu sababli ikkala limit birga ishlatiladi.
Global limit
Butun service uchun umumiy capacity belgilanadi.
Masalan:
10 000 request/minute
Bu backendni umumiy overload’dan himoya qiladi.
Bitta katta client barcha limitni egallamasligi uchun per-client limit ham kerak.
Per-user yoki per-tenant limit
Har user, API key, tenant yoki IP uchun alohida limit.
Bu fair usage va noisy neighbor muammosini kamaytiradi.
Key tanlashda NAT ortidagi ko‘p userni bitta IP sifatida cheklab qo‘ymaslik kerak.
Token bucket
Bucket ma’lum tezlikda token bilan to‘ladi.
Har request bir yoki bir nechta token sarflaydi.
Bucket capacity qisqa burstga ruxsat beradi.
Token tugasa request rad etiladi yoki kutadi.
Bu keng tarqalgan throttling algoritmi.
Leaky bucket
Requestlar bucketga keladi va barqaror tezlikda chiqadi.
Burst queue’da silliqlanadi.
Queue to‘lsa yangi requestlar tashlanadi.
Bu downstreamga tekis oqim berishga yordam beradi.
Fixed window
Masalan, har kalendar minut uchun 100 request.
Sodda, ammo window chegarasida burst mumkin:
12:00:59 da 100
12:01:00 da yana 100
Qisqa vaqtda 200 request keladi.
Sliding window
Oxirgi harakatlanuvchi vaqt oralig‘idagi requestlar sanaladi.
Fixed window boundary burstini kamaytiradi.
Aniq log modeli qimmat bo‘lishi mumkin.
Approximate counter yoki bucketlar ishlatiladi.
Concurrency semaphore
Bir operation uchun maksimal faol worker soni belgilanadi.
Masalan, tashqi payment providerga bir vaqtda 20 request.
Limit to‘lsa:
ishlatiladi.
Backpressure
Consumer producer tezligiga yetisha olmasa bosim yuqoriga uzatiladi.
Producer sekinlashadi yoki yangi data qabul qilmaydi.
Throttling backpressure’ning amaliy vositasi bo‘lishi mumkin.
Queue’ni cheksiz o‘stirish haqiqiy backpressure emas.
Response
HTTP API limit oshganda maxsus status qaytarishi mumkin.
ko‘rsatishi mumkin.
Client darhol agressiv retry qilmasligi kerak.
Delay
Request rad etilmasdan queue’da kutishi mumkin.
Bu background workload uchun mos.
Interactive request uzoq kutsa timeout va user tajribasi yomonlashadi.
Maksimal queue wait belgilanadi.
Priority
Kritik va oddiy requestlar turli quota oladi.
Masalan:
- production transaction;
- admin report;
- bulk export;
- background sync.
Priority starvation yaratmasligi kerak.
Past priority uchun minimal capacity ajratilishi mumkin.
Cost-based throttling
Barcha request bir xil xarajatga ega emas.
Bitta oddiy lookup 1 token, katta export 100 token sarflashi mumkin.
Cost CPU, database scan, payload yoki tashqi provider xarajatiga asoslanadi.
Adaptive throttling
Tizim healthiga qarab limit dinamik o‘zgaradi.
Latency oshsa yangi request capacity kamaytiriladi.
Stabilizatsiya bo‘lmasa limit tez-tez tebranadi.
Distributed limit
Bir service’ning ko‘p instance’i bo‘lsa global counter shared storage yoki distributed algoritm talab qiladi.
Local limiter tez, ammo har instance alohida quota beradi.
Load balancer notekis traffic tarqatsa limit ham notekis bo‘ladi.
Fail-open va fail-closed
Rate limit storage ishlamasa nima bo‘lishi belgilanadi.
Public content uchun fail-open, security-critical operation uchun fail-closed tanlanishi mumkin.
Throttling va Rate Limiting
Atamalar ko‘pincha bir-biriga yaqin ishlatiladi.
Rate limiting request sonini cheklashga urg‘u beradi.
Throttling esa oqimni sekinlashtirish, queue, concurrency va degradatsiyani ham qamrab olishi mumkin.
Client-side throttling
Client tashqi API quota’sini hurmat qilib requestlarini cheklaydi.
Bu serverdan 429 olishni kamaytiradi.
Ko‘p client instance bo‘lsa umumiy quota muvofiqlashtirilishi kerak.
Observability
Kuzatiladi:
- accepted;
- delayed;
- rejected;
- active concurrency;
- queue depth;
- wait time;
- tenant;
- operation;
- limit utilization.
User ID kabi yuqori cardinality metric labeldan saqlaniladi.
Test
Burst, sustained load, distributed instance, clock boundary, storage failure, retry va priority holatlari test qilinadi.
Load test real dependency limitlarini hisobga oladi.
Faqat unit test algoritmning production xatti-harakatini to‘liq ko‘rsatmaydi.
Load shedding
Tizim capacity’dan oshganda eng arzon va past priority requestlarni erta rad etishi mumkin.
Bu qimmat operationlar boshlanganidan keyin xato berishdan ko‘ra resource’ni tejaydi.
Health check va kritik control traffic uchun alohida reserve capacity saqlanadi.
Quota refill
Uzun muddatli quota, masalan kunlik limit, burst rate limitdan alohida yuritiladi.
Client soniyalik limitga mos bo‘lsa ham kunlik quota tugashi mumkin.
Response qaysi limit ishlaganini aniq ko‘rsatadi.
Fair queue
Bir nechta tenant requestlari alohida queue yoki weighted fair scheduling orqali aralashtiriladi.
Katta tenant kichik tenantlarning barcha worker slotlarini egallab olmasligi kerak.
Bog‘liq tushunchalar
Rate limiting, Token bucket, Leaky bucket, Backpressure, Concurrency limit, Queue, Load shedding, Retry-After, Quota, Bulkhead