Rate Limiting - Backenddagi Qalqon🛡️

Siz o'z tizimingizga qancha resurs ajratmang, uning baribir o'z chegarasi bor. Ba'zida trafik kutilmaganda keskin oshadi (bursts), userlar agressiv retry qiladi yoki bitta servisdagi muammo butun tizimni ishdan chiqaradi. Aynan shunday paytlarda Rate Limiting (so'rovlarni cheklash) ancha as qotadi.

Oddiy qilib aytganda, Rate Limiter - bu API oldida turgan "qo'riqchi" (bouncer). U tizimga kirayotgan so'rovlar oqimini nazorat qilib turadi, serverlarni haddan tashqari yuklanishiga, brute-force hujumlariga va boshqa shunga o'xshash holatlarga yo'l qo'ymaydi. Agar klient belgilangan me'yordan oshsa, Rate Limiter unga ko'pchilik ko'rgan 429 Too Many Requests xatoligini qaytaradi.

Hozir eng keng tarqalgan Rate Limiting algoritmlarini ko'rib chiqamiz:

1. Fixed Window Counter
Bu eng oddiy usul. Vaqt qat'iy oraliqlarga ("windows") bo'linadi (masalan, har daqiqada). Har bir oyna uchun so'rovlar hisoblagichi (counter) bo'ladi.

Qanday ishlaydi: Agar daqiqasiga 100 ta so'rov limiti bo'lsa, 14:00 da hisoblagich 0 ga tushadi va 14:01 gacha kelgan so'rovlarni sanaydi. 101-so'rov rad etiladi. 14:01 da hisoblagich yana 0 ga tushadi.

Asosiy muammo: Oyna chegarasidagi yuklama. Masalan, klient 14:00:59 da 100 ta va 14:01:01 da yana 100 ta so'rov yuborishi mumkin. Natijada tizim 2 soniya ichida 200 ta so'rov qabul qiladi, bu esa limitimizda yanayam qo'shimcha limitlar keltiradi.

2. Sliding Window Log
Bu usul yuqoridagi muammoni hal qiladi. U har bir so'rovning timestamp'ini (vaqt belgisini) saqlaydi.

Qanday ishlaydi: Yangi so'rov kelganda, algoritm joriy vaqtdan bir oyna (masalan, 1 daqiqa) orqadagi barcha timestamp'larni o'chiradi. Qolgan timestamp'lar soni limitdan oshmasa, so'rov qabul qilinadi va uning timestamp'i jurnalga qo'shiladi.

Afzalligi: Juda aniq ishlaydi, chegara muammosi yo'q.

Kamchiligi: Har bir foydalanuvchining har bir so'rovi uchun timestamp saqlash katta trafikda juda ko'p xotira talab qilishi mumkin.

3. Sliding Window Counter
Bu - avvalgi ikki usulning yaxshi tomonlarini birlashtirgan gibrid yondashuv, "oltin o'rtalik".

Qanday ishlaydi: Bu usul timestamp'lar jurnalini saqlamaydi. Buning o'rniga, u oldingi va joriy oynalardagi hisoblagichlardan foydalanib, sliding windowdagi so'rovlar sonini taxminan hisoblaydi. Bu orqali resurs sarfiyam, aniqligam yaxshi muvozanatlanadi.

Afzalligi: Xotirani tejamkorligi va yetarlicha aniqlik. Ko'pgina yirik tizimlar aynan shu yondashuvdan foydalanadi.

4. Token Bucket
Bu eng mashhur va moslashuvchan strategiyalardan biri.

Tasavvur qiling, bir chelak (bucket) bor va unga doimiy tezlikda "token"lar solib turiladi. Har bir kiruvchi so'rov o'tish uchun chelakdan bitta token olishi kerak. Agar chelakda token bo'lmasa, so'rov rad etiladi yoki navbatga qo'yiladi.

Eng muhim xususiyati: Qisqa muddatli keskin yuklamalarga (bursts) ruxsat beradi. Agar chelak tokenlarga to'la bo'lsa, klient bir vaqtning o'zida chelak sig'imicha so'rov yuborishi mumkin. Bu tizimga moslashuvchanlik beradi.

5. Leaky Bucket
Bu strategiya Token Bucket'ga o'xshaydi, lekin boshqacha maqsadda xizmat qiladi.

Qanday ishlaydi: Kiruvchi so'rovlar qanchalik tez kelishidan qat'iy nazar, chelakka (bu yerda u FIFO - first in first out navbati) tushadi. Chelak esa o'z "tubidan" doimiy bir xil tezlikda so'rovlarni "oqizib" chiqaradi va tizimga uzatadi. Agar chelak (navbat) to'lib qolsa, yangi so'rovlar rad etiladi.

Eng muhim xususiyati: Chiquvchi oqimni doimiy bir tekis tezlikda ushlab turadi. U burst'larni "siyqallaydi" va tizimga so'rovlarni barqaror oqimda yetkazib beradi.

Xulosa qilib aytadigan bo'lsak, eng yaxshi algoritm yo'q. Tanlov sizning talablaringizga bog'liq: agar tizimingiz qisqa muddatli burst'larni qabul qila olsa, Token Bucket yaxshi tanlov. Agar sizga tizimga tushadigan yuklamani doimiy va bir tekisda ushlab turish muhim bo'lsa, Leaky Bucket yoki Sliding Window strategiyalari ko'proq mos keladi.

@mabrur_dev