API दर सीमा नीति सिम्युलेटर

--- name: api-rate-limit-policy-simulator description: शिप करने से पहले API रेट लिमिट्स का सिमुलेशन करता है - टोकन बकेट, फिक्स्ड विंडो, स्लाइडिंग लॉग और स्लाइडिंग काउंटर, प्रति क्लाइंट, एंडपॉइंट, टियर या ग्लोबल - जेनरेट या रिकॉर्ड किए गए ट्रैफ़िक पर रीट्राई करने वाले क्लाइंट्स के साथ। दिखाता है कि किसे 429 मिलते हैं और कितनी देर के लिए, फिक्स्ड-विंडो बाउंड्री बर्स्ट, रीट्राई हर्ड्स, शोरगुल वाले पड़ोसी, दुरुपयोग करने वाले क्लाइंट जो फिर भी पास हो जाते हैं और बैकएंड क्षमता से अधिक पीक। ऑफ़लाइन stdlib Python सिम्युलेटर --self-test के साथ शामिल है। --- # API रेट लिमिट पॉलिसी सिम्युलेटर आप बैकएंड और प्लेटफ़ॉर्म इंजीनियरों को सटीक संख्याओं के बजाय सबूतों के साथ रेट लिमिट चुनने में मदद करते हैं। एक लिमिट जो कागज़ पर सुरक्षित लगती है ("300 प्रति मिनट प्रति की") फिर भी विंडो बाउंड्री पर उसका 1.8 गुना पास कर सकती है, एक मोबाइल ऐप को थ्रॉटल कर सकती है जिसके हज़ारों उपयोगकर्ता एक API की साझा करते हैं, रीसेट सेकंड पर रीट्राई का झुंड छोड़ सकती है, और एक स्क्रैपर के खिलाफ कुछ नहीं करती जो उसके ठीक नीचे रहता है। आप पॉलिसी और ट्रैफ़िक को एक छोटी JSON फ़ाइल में वर्णित करते हैं, उसे रीप्ले करते हैं, और परिणाम क्लाइंट-दर-क्लाइंट और पॉलिसी-दर-पॉलिसी पढ़ते हैं। ## इस स्किल में फ़ाइलें - `scripts/rate_sim.py` - टोकन बकेट, फिक्स्ड विंडो, स्लाइडिंग लॉग और स्लाइडिंग काउंटर लिमिटर्स का सिमुलेशन करता है जो क्लाइंट, एंडपॉइंट, क्लाइंट+एंडपॉइंट या ग्लोबल द्वारा की गई हैं, एंडपॉइंट्स और क्लाइंट टियर्स तक सीमित; स्थिर, पॉइसन या बर्स्ट ट्रैफ़िक उत्पन्न करता है (या CSV ट्रेस रीप्ले करता है), क्लाइंट्स को तुरंत रीट्राई करने देता है, बैकऑफ़ के साथ या Retry-After का सम्मान करते हुए, और 429s, देरी, विफलताएं, सबसे खराब स्थिति और देखी गई विंडो गणनाएं, क्षमता बनाम पीक, निष्कर्ष RL01-RL10 और एक नमूना 429 प्रतिक्रिया रिपोर्ट करता है (केवल Python 3.8+ मानक पुस्तकालय) - `references/algorithms.md` - प्रत्येक एल्गोरिदम कैसे व्यवहार करता है, उसकी सबसे खराब स्थिति, मेमोरी लागत और इसे कब चुनें - `references/policy-design.md` - कुंजियाँ, टियर, संख्याएं, हेडर और क्लाइंट रीट्राई नियम चुनना; फाइंडिंग कोड का क्या मतलब है - `templates/rate-limit-review.md` - वापस देने के लिए समीक्षा - `examples/orders-api.json` - एक सार्वजनिक ऑर्डर API जिसमें प्रति-की फिक्स्ड विंडो, एक लॉगिन लिमिट और एक ग्लोबल फिक्स्ड विंडो है; पाँच क्लाइंट जिनमें एक साझा मोबाइल की, एक बल्क पार्टनर, एक स्क्रैपर और एक क्रेडेंशियल स्टफर शामिल हैं - `examples/orders-api-report.md` - उस फ़ाइल पर वास्तविक सिम्युलेटर आउटपुट - `examples/orders-api-tuned.json` - फिक्स के बाद वही API: प्रति-टियर टोकन बकेट, क्षमता के आकार का एक ग्लोबल टोकन बकेट ## वर्कफ़्लो ### 1. इनपुट एकत्र करें पूछें: आज कॉन्फ़िगर की गई या प्रस्तावित लिमिट्स (एल्गोरिदम, की, संख्याएं, कौन से एंडपॉइंट्स और कौन से क्लाइंट), वे कहाँ लागू हैं (गेटवे, CDN, ऐप, Redis), बैकएंड क्षमता प्रति सेकंड अनुरोधों में जो यह सहन कर सकता है, और ट्रैफ़िक: सबसे बड़े वैध क्लाइंट और उनका आकार (स्थिर, बर्स्टी बैच जॉब, एक की या एक NAT IP के पीछे कई उपयोगकर्ता), प्रत्येक कैसे रीट्राई करता है, और लॉग में देखा गया कोई दुरुपयोग। वास्तविक एक्सेस लॉग अनुमानों से बेहतर हैं: व्यस्त 5-15 मिनट के लिए `t,client,endpoint` निर्यात करें और इसे `--trace` के साथ पास करें। ### 2. सिम्युलेटर चलाएं ``` python3 scripts/rate_sim.py examples/orders-api.json python3 scripts/rate_sim.py examples/orders-api-tuned.json python3 scripts/rate_sim.py policies.json --trace access-sample.csv python3 scripts/rate_sim.py policies.json --json python3 scripts/rate_sim.py --self-test ``` निकास 0 = कोई उच्च निष्कर्ष नहीं, 1 = उच्च निष्कर्ष (वैध क्लाइंट थ्रॉटल किए गए या स्वीकृत ट्रैफ़िक क्षमता से अधिक), 2 = गलत इनपुट। शेल के बिना, `references/algorithms.md` के साथ तर्क करें: प्रति की, क्लाइंट के प्रति विंडो पीक की तुलना लिमिट से करें, सबसे खराब स्थिति (फिक्स्ड विंडो के लिए 2x लिमिट, बकेट के लिए बर्स्ट + रेट) की तुलना क्षमता से करें, और सोचें कि 429 के बाद प्रत्येक क्लाइंट क्या करता है। ### 3. परिणाम पढ़ें - पहले वैध क्लाइंट (RL01): कोई विफल या विलंबित अनुरोध, और उन्होंने कितनी देर इंतज़ार किया। एक ऐप के उपयोगकर्ताओं द्वारा साझा की गई एक की को अपना टियर या प्रति-उपयोगकर्ता की चाहिए। - क्षमता (RL03): स्वीकृत पीक सेकंड बनाम जो बैकएंड सहन करता है। केवल एक ग्लोबल लिमिट क्षमता की रक्षा करती है; प्रति-की लिमिट्स कुंजियों की संख्या से गुणा होती हैं। - आकार (RL04, RL10): फिक्स्ड विंडो बाउंड्री पर बर्स्ट पास करती हैं और एक बार में पूरी विंडो देती हैं; बिना जिटर के रीट्राई सभी एक ही सेकंड में वापस आते हैं। - दुरुपयोग (RL02): प्रति-की लिमिट के नीचे रहने वाला स्क्रैपर लिमिट्स से नहीं रुकता; उसे डिटेक्शन, प्रमाणीकरण या प्रति-एंडपॉइंट लिमिट की आवश्यकता है। - रीट्राई (RL05): प्रति तार्किक अनुरोध 1.5 से अधिक प्रयासों का मतलब है कि क्लाइंट थ्रॉटल होने पर लोड बढ़ाते हैं। ### 4. ट्यून करें और फिर से चलाएं एक समय में एक चीज़ बदलें और उसी ट्रैफ़िक के साथ फिर से चलाएं: फिक्स्ड विंडो को टोकन बकेट या स्लाइडिंग काउंटर में बदलें, `clients` / `exclude_clients` के साथ टियर जोड़ें, ग्लोबल बकेट को क्षमता के आकार का बनाएं (रेट = स्थायी rps, बर्स्ट = जो बैकएंड एक सेकंड के लिए अवशोषित करता है), लॉगिन और महंगे कॉल के लिए एंडपॉइंट लिमिट्स जोड़ें, और बैच पार्टनर्स के साथ पेसिंग सहमत करें। संख्याओं के लिए `references/policy-design.md` का उपयोग करें। ### 5. डिलीवर करें `templates/rate-limit-review.md` भरें: फैसला, प्रति क्लाइंट पहले/बाद की तालिका, कॉन्फ़िगरेशन के रूप में पॉलिसी परिवर्तन, 429 प्रतिक्रिया और हेडर, क्लाइंट मार्गदर्शन (Retry-After, जिटर के साथ बैकऑफ़, अधिकतम रीट्राई) और रोलआउट के बाद क्या मॉनिटर करें। ## उदाहरण परिणाम `examples/orders-api.json` पर साझा `mobile-app` की 300/मिनट प्रति-की विंडो से टकराती है: इसके 1,839 अनुरोधों में से 1,042 केवल 60 सेकंड तक इंतज़ार करने के बाद सफल होते हैं (RL01, उच्च)। बिना जिटर के Retry-After का सम्मान करने से सेकंड 240 में 289 रीट्राई निकलते हैं, इसलिए स्वीकृत ट्रैफ़िक 80 की क्षमता के खिलाफ 313 req/s पर पीक करता है (RL03, RL10)। प्रति-की फिक्स्ड विंडो एक रोलिंग मिनट में 544 अनुरोध पास करती है (1.8x, RL04), और स्क्रैपर को अभी भी इसके 45% कॉल मिलते हैं जबकि इसकी तत्काल रीट्राई इसे 2.67 प्रयास प्रति अनुरोध तक ले जाती हैं। लॉगिन लिमिट क्रेडेंशियल स्टफर को रोकती है (480 में से 40)। `examples/orders-api-tuned.json` में (टियर टोकन बकेट, ग्लोबल बकेट 50 req/s + 30 बर्स्ट, पार्टनर पेसिंग 2 req/s पर) वैध क्लाइंट को कोई 429 नहीं मिलता, पीक 27 req/s है और केवल स्क्रैपर निष्कर्ष बचे हैं। ## नियम - उस ट्रैफ़िक के साथ सिमुलेशन करें जो आपके पास वास्तव में है (या एक ट्रेस), औसत के साथ नहीं; बर्स्ट और रीट्राई वही हैं जहाँ लिमिट्स विफल होती हैं। - किसी लिमिट को क्षमता के लिए सुरक्षित कभी न कहें जब तक कि एक ग्लोबल लिमिट कुल को सीमित न करे। - वैध क्लाइंट के विलंबित अनुरोधों को सफलता के रूप में नहीं, बल्कि हानि के रूप में मानें। - हमेशा Retry-After के साथ 429 लौटाएं, जिटर जोड़ें, और क्लाइंट्स को बताएं कि कैसे बैकऑफ़ करना है। - रेट लिमिट्स अपने आप में दुरुपयोग सुरक्षा नहीं हैं; कहें जब प्रमाणीकरण, बॉट डिटेक्शन या WAF नियम आवश्यक हों। - परिणाम एक मॉडल हैं: रोलआउट के बाद गेटवे मेट्रिक्स के साथ पुष्टि करें और लिमिट्स को कोड में नहीं, कॉन्फ़िगरेशन में रखें।