तपाईं रेट लिमिटिङ कसरी डिजाइन गर्नुहुन्छ?

Question

Accepted Answer

**रेट लिमिटिङ** ले क्लायन्टले एक समय खिडकीमा कति अनुरोध गर्न सक्छ भनेर प्रतिबन्ध गर्छ — प्रणाली को दुरुपयोग, ओभरलोड बाट सुरक्षा र न्यायसंगत प्रयोग सुनिश्चित गर्छ। यो एक सामान्य प्रणाली-डिजाइन घटक हो, जसमा धेरै एल्गोरिदम र विचारहरू छन्।

## रेट लिमिटिङ किन गरिन्छ

```text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
```

## रेट लिमिटिङ एल्गोरिदम

```text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
  ✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
  the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)
```

## कार्यान्वयन विचारहरू

```text
✓ DISTRIBUTED → limits must be shared across servers → use a centralized store (REDIS is
  common: atomic counters, fast, shared across instances)
✓ Identify the client → by API key, user ID, IP
✓ Return clear responses → HTTP 429 (Too Many Requests); include limit/retry-after headers
✓ Where → at the API gateway, load balancer, or application layer
✓ Granularity → per user, per endpoint, global; different tiers/limits
```

## यो किन महत्त्वपूर्ण छ

रेट लिमिटिङ कसरी डिजाइन गर्ने भनेर बुझ्न मूल्यवान छ किनभने यो प्रणाली सुरक्षित गर्न र न्यायसंगत प्रयोग सुनिश्चित गर्न **सामान्य प्रणाली-डिजाइन घटक** हो, त्यसैले यो महत्त्वपूर्ण व्यावहारिक ज्ञान हो।

रेट लिमिटिङ — क्लायन्टले एक समय खिडकीमा कति अनुरोध गर्न सक्छ भनेर प्रतिबन्ध गर्नु — महत्त्वपूर्ण आवश्यकताहरू सम्बोधन गर्छ: **दुरुपयोग विरुद्ध सुरक्षा** (brute force, scraping, र DoS जस्ता आक्रमण रोकिङ), **ओभरलोड रोकिङ** (प्रणाली स्थिरता सुरक्षित गर्दै), **न्यायसंगत प्रयोग** सुनिश्चित गर्दै (कुनै पनि क्लायन्ट स्रोत एकाधिकार गरिरहेको छैन, नि:शुल्क बनाम भुक्तानी गरिएको जस्ता स्तरीय सीमा समर्थन गर्दै), र लागत नियन्त्रण।

यसले रेट लिमिटिङ API र सेवाहरूको लागि सामान्य आवश्यकता बनाउँछ।

**एल्गोरिदम** र तिनीहरूको ट्रेड-अफ्स बुझ्नु — **निश्चित खिडकी** (सरल तर सीमा को burst अनुमति दिन्छ), **स्लाइडिङ खिडकी** (अधिक सहज र सटीक), **टोकन बाल्टी** (नियन्त्रित burst अनुमति दिन्छ जबकि औसत दर सीमित गर्छ — लोकप्रिय र लचकदार), र leaky bucket (आउटपुट सहज गर्दै) — मुख्य डिजाइन ज्ञान हो, किनभने सही एल्गोरिदम चयन व्यवहार प्रभावित गर्छ।

**कार्यान्वयन विचारहरू** बुझ्न विशेष गरी महत्त्वपूर्ण छ: **वितरित रेट लिमिटिङ** सम्भालिङ (सीमाहरू बहु सर्भर मा साझा गरिएको, सामान्यतया उदाहरण भर साझा गरिएको छिटो atomic counter को लागि **Redis** प्रयोग गर्दै — किनभने प्रति-सर्भर सीमा वितरित प्रणालीमा काम गर्दैन), क्लायन्ट पहिचान गर्नु (API key, user, वा IP द्वारा), स्पष्ट प्रतिक्रिया फिर्ता गर्नु (HTTP 429 retry-after header को साथ), यो लागू गर्न कहाँ चयन गर्नु (gateway, load balancer, वा application), र granularity (प्रति user, प्रति endpoint, स्तरीय)।

यस ले वास्तविक वितरित प्रणालीमा काम गर्ने रेट लिमिटिङ डिजाइन गर्ने प्रतिफलित गर्छ।

रेट लिमिटिङ एक बारम्बार आवश्यक पर्ने घटक हो, प्रायः प्रणाली डिजाइन छलफल र साक्षात्कारमा देखिन्छ।

रेट लिमिटिङ प्रणाली सुरक्षित गर्न (दुरुपयोग र ओभरलोडबाट) र न्यायसंगत प्रयोग सुनिश्चित गर्न एक सामान्य, महत्त्वपूर्ण घटक भएको कारण, र एल्गोरिदम, तिनीहरूको ट्रेड-अफ्स, र विशेष गरी वितरित कार्यान्वयन (Redis को माध्यमबाट साझा सीमा) बुझ्न महत्त्वपूर्ण भएको कारण, रेट लिमिटिङ कसरी डिजाइन गर्ने भनेर बुझ्न मूल्यवान, व्यावहारिक-प्रासंगिक प्रणाली-डिजाइन ज्ञान हो — सेवा सुरक्षित गर्न र न्यायसंगत प्रयोग सुनिश्चित गर्न एक सामान्य घटक, एल्गोरिदम र वितरित कार्यान्वयन बुझ्न आवश्यक पर्छ, र मजबूत, सुरक्षित प्रणाली निर्माण को लागि प्रणाली डिजाइनमा एक बारम्बार-छलफल गरिने विषय।