टीएल;डीआर
- समस्या: बड़े पैमाने की वास्तुकला (आर्किटेक्चर) तैयार करने के लिए उपलब्धता, थ्रूपुट और परिचालन जटिलता के बीच संतुलन बनाना आवश्यक है।
- मुख्य निष्कर्ष: बिल्कुल शुरुआती लोगों के लिए रेट लिमिटिंग: क्लब के बाउंसर की उपमा, सीमाएँ क्यों हैं, टोकन बकेट और स्लाइडिंग विंडो साफ़ भाषा में, साझा नोटबुक के रूप में रेडिस, और एक अनुरोध शुरू से अंत तक।
- परिणाम: उत्पादन वातावरण में विफलता से निपटने और प्रदर्शन लक्ष्यों को हासिल करने की सटीक रूपरेखा।
एक व्यस्त शनिवार रात का क्लब सोचें। दरवाज़े पर बाउंसर का काम सीधा है: कमरे जितना सँभल सके, उतनी रफ़्तार से लोगों को अंदर आने देना। एक साथ बहुत ज़्यादा आए तो बार, बाथरूम और निकास सब फेल हो जाते हैं। बहुत सख्त हो तो ईमानदार मेहमान नाराज़ होकर चले जाते हैं। रेट लिमिटर आपकी एपीआई के लिए वही बाउंसर है। हर अनुरोध आकर पूछता है: "क्या मैं अभी अंदर आ सकता हूँ?" लिमिटर हाँ, इंतज़ार, या नहीं कहता है।
यह पोस्ट रेट लिमिटिंग को एक धैर्यवान प्रोफ़ेसर की तरह सिखाता है: पहले मानवीय कारण, फिर वे दो एल्गोरिदम जो आपको असल में मिलेंगे, फिर कई सर्वर का जाल, फिर एक अनुरोध का पूरा सफ़र। आपको वितरित सिस्टम का अनुभव ज़रूरी नहीं। जिज्ञासा चाहिए, और कुछ मिनट टिकट व पानी के बाल्टी से सोचने की तैयारी।
रेट लिमिट क्यों होते हैं (साधारण भाषा में)
बिना बाउंसर के तीन दर्द जल्दी दिखते हैं।
निष्पक्षता। एक व्यक्ति रिफ़्रेश दबा-दबाकर पूरा कमरा खा सकता है। बाकी इंतज़ार करते हैं। रेट लिमिट हर मेहमान (यूज़र, आईपी, एपीआई कुंजी) को बजट देते हैं ताकि एक शोर करने वाला पड़ोसी बाकी को भूखा न छोड़े।
लागत। हर अनुरोध की कीमत होती है: सीपीयू, डेटाबेस समय, थर्ड-पार्टी एसएमएस या एआई एपीआई का पैसा। असीमित मुफ़्त ट्रैफ़िक = असीमित मुफ़्त बिल। लिमिट फ़्री टियर को फ़्री रखने और पेड टियर को ईमानदार रखने का तरीका है।
दुरुपयोग। बॉट पासवर्ड अनुमान लगाते हैं, कैटलॉग स्क्रैप करते हैं, या साइनअप स्पैम करते हैं। लिमिट दृढ़ हमलावर को हमेशा के लिए नहीं रोकती, लेकिन सस्ते हमलों को इतना धीमा कर देती है कि लॉग, कैप्चा और सुरक्षा टीम साँस ले सकें।
प्रोडक्ट भाषा जो आप पहले से जानते हैं:
- फ़्री प्लान: दिन में १०० एपीआई कॉल।
- लॉगिन: कुछ कोशिशें, फिर ठंडा होना।
- मौसम एपीआई: प्रति कुंजी प्रति मिनट ६० अनुरोध।
हर जगह एक ही विचार: समय के साथ कार्यों का बजट।
आप क्या गिन रहे हैं
एल्गोरिदम चुनने से पहले तय करें किसे सीमित कर रहे हैं और एक "टिकट" क्या मतलब रखता है।
| गिनती किससे... | असल जीवन का अर्थ | कब बिगड़ता है |
|---|---|---|
| आईपी पता | "यह फ़ोन नेटवर्क" | कई लोग एक आईपी साझा करते हैं (ऑफ़िस, मोबाइल कैरियर) |
| यूज़र आईडी | "यह लॉग-इन व्यक्ति" | साझा बॉट अकाउंट या भूले सर्विस यूज़र |
| एपीआई कुंजी | "यह पार्टनर ऐप" | एक कुंजी कई जगहों से एक साथ |
| टेनेंट + रूट | "यह कंपनी इस महँगे एंडपॉइंट पर" | एक गरम फ़ीचर पूरी कंपनी का कोटा जला देता है |
| सब मिलकर | "साझा रसोई की रक्षा" | एक शोर करने वाला टेनेंट प्लेटफ़ॉर्म को नुकसान पहुँचाता है |
अच्छा लिमिटर तीन बातों का जवाब देता है:
१. अनुमति या अस्वीकार (अभी हाँ या नहीं)।
२. अस्वीकार पर कितना इंतज़ार (Retry-After जैसी मार्गदर्शिका)।
३. कितना बजट बचा ताकि क्लाइंट विनम्रता से धीमा हो।
एचटीटीपी स्टेटस ४२९ का मतलब है "बहुत ज़्यादा अनुरोध।" इसे बाउंसर का विनम्र "अभी नहीं" समझें।
दो मानसिक मॉडल जो हमेशा काम आएंगे
इंटरव्यू और प्रोडक्शन दोनों इन्हीं दो विचारों के इर्द-गिर्द घूमते हैं। इन्हें सिर में तस्वीरों से सीखें, केवल सूत्रों से नहीं।
१. टोकन बकेट = टिकटों की पानी की जग
काउंटर पर एक जग सोचें। उसमें बी टिकट समा सकते हैं (क्षमता)। हर सेकंड (या मिनट) क्लब जग में आर नए टिकट डालता है (रिफ़िल दर)। जब आप आते हैं, एक टिकट चाहिए। जग में हो तो ले लें और अंदर जाएँ। खाली हो तो इंतज़ार।
ज़रूरी एहसास:
- क्लब शांत हो तो टिकट भरते रहते हैं जब तक जग भरी न हो। फिर छोटी बर्स्ट (एक साथ बी लोग तक) दे सकते हैं।
- बर्स्ट के बाद जग खाली। नए मेहमान उतनी ही तेज़ी से आते हैं जितनी तेज़ी से टिकट भरते हैं (दर आर)।
- बर्स्ट आकार और लंबी-अवधि की गति अलग घुंडियाँ हैं। प्रोडक्ट को यही पसंद: "छोटा स्पाइक दें, हमेशा के लिए आर से ज़्यादा कभी नहीं।"
यही टोकन बकेट है। टोकन = टिकट। क्षमता = कितने अतिरिक्त टिकट रखते हैं। दर = कितनी तेज़ी से नए बनाते हैं।
२. स्लाइडिंग विंडो = समय की लुढ़कती पट्टी
टिकट काउंटर सोचें जो केवल पिछले ६० सेकंड देखता है, "इस कैलेंडर मिनट" नहीं। काँच की खिड़की टाइमलाइन पर सरकती है। आप गिनते हैं उस काँच के नीचे कितने लोग आए। गिनती सीमा से कम हो तो अगले को मुहर। नहीं तो पुरानी मुहरें विंडो से बाहर गिरने तक इंतज़ार।
दो आम रूप:
स्लाइडिंग विंडो लॉग (सटीक, महँगा): हर प्रवेश का टाइमस्टैम्प लिखें। नए व्यक्ति पर ६० सेकंड से पुरानी मुहरें मिटाएँ और बाकी गिनें। पूरी तरह निष्पक्ष। लाखों लोग मारें तो भारी, क्योंकि हर अनुरोध लिखना और साफ़ करना है।
स्लाइडिंग विंडो काउंटर (काफ़ी अच्छा, व्यावहारिक): हर मुहर की जगह दो मोटे बाल्टी: "पिछला मिनट" और "वर्तमान मिनट।" वर्तमान मिनट कितना बीता, उसी से मिलाएँ। लगभग लॉग जितना चिकना, लंबी सूची की जगह दो संख्याएँ।
फिक्स्ड विंडो भोला चचेरा भाई है: "कैलेंडर मिनट में सिर्फ़ १००।" 12:00:59 पर कोई १०० इस्तेमाल करे। 12:01:00 पर काउंटर रीसेट, फिर १००। दो सेकंड में २००। नरम सीमाएँ सहती हैं। सख्त एसएलए अक्सर नहीं।
| विचार | रोज़मर्रा की तस्वीर | बर्स्ट का एहसास | मेमोरी लागत |
|---|---|---|---|
| फिक्स्ड विंडो | हर मिनट की शुरुआत पर क्लिकर रीसेट | किनारों पर स्पाइक | बहुत कम (एक काउंटर) |
| स्लाइडिंग लॉग | पिछले ६० सेकंड की सटीक मेहमान सूची | चिकना और निष्पक्ष | बड़ी |
| स्लाइडिंग काउंटर | दो मिनटों का अनुमानित मिश्रण | लगभग चिकना | बहुत कम (दो काउंटर) |
| टोकन बकेट | धीरे भरने वाली टिकट जग | नियंत्रित बर्स्ट | बहुत कम |
| लीकी बकेट | स्थिर बूँद-बूँद से खाली होने वाला सिंक | चिकना आउटफ़्लो | कतार या काउंटर |
लीकी बकेट (अतिरिक्त तस्वीर): लोग कतार में लगते हैं, दरवाज़ा हर निश्चित टिक पर एक को जाने देता है, जैसे सिंक स्थिर दर से रिसता हो। आउटपुट चिकना। कतार भरी हो तो नए मुड़ जाते हैं। जब सुरक्षित चीज़ को छोटे स्पाइक से ज़्यादा स्थिर आगमन चाहिए, तब उपयोगी।
ज़्यादातर एपीआई के लिए टोकन बकेट या स्लाइडिंग विंडो काउंटर मीठा बिंदु है।
सबसे सरल कोड आकार में टोकन बकेट
एक प्रोसेस, एक घड़ी, अभी रेडिस नहीं। जग कोड रूप में:
import time
class TokenBucket:
def __init__(self, rate: float, capacity: float):
self.rate = rate # प्रति सेकंड जुड़े टिकट
self.capacity = capacity # जग में अधिकतम टिकट
self.tokens = capacity
self.updated_at = time.monotonic()
def allow(self, cost: float = 1.0) -> bool:
now = time.monotonic()
elapsed = now - self.updated_at
# बीते समय के हिसाब से भरें, क्षमता से ऊपर नहीं
self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
self.updated_at = now
if self.tokens >= cost:
self.tokens -= cost
return True
return False
सावधान प्रोफ़ेसर जो रेखांकित करेगा:
- रिफ़िल गणित के लिए स्थिर घड़ी (मोनोटोनिक) चुनें, ताकि लैपटॉप की घड़ी कूदकर मुफ़्त टिकट न गढ़े।
- लागत १ से ज़्यादा हो सकती है। महँगा "सारा डेटा एक्सपोर्ट" रूट १० टिकट ले सकता है; सस्ता हेल्थ चेक १ या ० भी।
- एक प्रोसेस डेमो के लिए ठीक। कई सर्वर को साझा जग चाहिए, वरना हर सर्वर अपना पूरा बजट वाला बाउंसर बन जाता है।
कई सर्वर: निजी नोटबुक बनाम एक साझा नोटबुक
मल्टी-सर्वर जाल साफ़ भाषा में।
लोड बैलेंसर के पीछे एपीआई की २० प्रतियाँ चल रही हैं। हर प्रति अपनी निजी नोटबुक रखती है: "इस यूज़र ने १०० में से ५ इस्तेमाल किए।" यूज़र २०ों को मार सकता है। ट्रैफ़िक समान बँटे तो उन्हें असल में कोई "ना" सुनने से पहले लगभग २० × १०० मिल जाता है। आपकी घोषित सीमा कल्पना बन गई।
| तरीका | तस्वीर | असल में क्या होता है |
|---|---|---|
| केवल ऐप मेमोरी में लिमिट | हर बाउंसर की निजी नोटबुक | बजट सर्वर संख्या से गुणा |
| केवल स्टिकी सेशन | "हमेशा उसी दरवाज़े पर भेजो" | रिट्राई और मोबाइल नेटवर्क स्टिकनेस तोड़ देते हैं |
| साझा स्टोर (अक्सर रेडिस) | एक नोटबुक जिसे सब पढ़ें-लिखें | असल सीमा लगभग असल सीमा रहती है |
रेडिस कई टीमों की पसंदीदा साझा नोटबुक है: बहुत तेज़, साधारण काउंटर और छोटे हैश में अच्छा, स्क्रिप्ट जो एक कुंजी को बिना दो ऐप की रेस के अपडेट करे।
वे पैटर्न जो लोग असल में शिप करते हैं
फिक्स्ड विंडो नोटबुक पेज
key = rl:{apiKey}:{yyyyMMddHHmm}
count = INCR key
if count == 1: EXPIRE key 120
if count > limit: DENY
सस्ता और सरल। किनारे के स्पाइक सहें अगर प्रोडक्ट सह सके।
साझा हैश पर टोकन बकेट
एक रेडिस कुंजी पर tokens और last_refill_time रखें। हर अनुरोध पर छोटी लुआ स्क्रिप्ट (रेडिस पर एक एटॉमिक कदम) समय से रिफ़िल करे, संभव हो तो टोकन खर्च करे, नया शेष लिखे, और अनुमति/अस्वीकार व बचे टिकट लौटाए। बिना एटॉमिक अपडेट के दो सर्वर दोनों "१ बचा" पढ़ सकते हैं, दोनों अनुमति दें, और आखिरी टिकट ओवरसेल हो जाए।
सॉर्टेड सेट के रूप में स्लाइडिंग लॉग
टाइमस्टैम्प रखें, पुराने हटाएँ, गिनें, नई मुहर जोड़ें। सटीक, लेकिन मेमोरी और सीपीयू ट्रैफ़िक के साथ बढ़ते हैं। ऊँचे क्यूपीएस पर अक्सर यही पहला पैटर्न होता है जिसका पछतावा होता है।
दो पेजों वाला स्लाइडिंग काउंटर
"यह विंडो" और "पिछली विंडो" की कुंजियाँ, भार से मिश्रित। लगभग सारी चिकनाई, कम लागत।
फेल-ओपन बनाम फेल-क्लोज़्ड (जब नोटबुक गायब हो)
रेडिस डाउन हो तो भी नीति चाहिए:
- फेल-ओपन: ट्रैफ़िक जाने दें (शायद छोटी स्थानीय आपातकालीन सीमा के साथ)। उपभोक्ता ऐप अक्सर यह चुनते हैं ताकि रेडिस दर्द कुल आउटेज न बने।
- फेल-क्लोज़्ड: अस्वीकार। भुगतान और लॉगिन अक्सर यह चुनते हैं ताकि अराजकता का मतलब मुफ़्त असीमित कोशिशें न हो।
कोई भी मुफ़्त नहीं। सतह के हिसाब से जानबूझकर चुनें, और दोनों मामलों में रेडिस त्रुटियों पर अलार्म।
घड़ियाँ झूठ बोलेंगी अगर आप उन्हें छोड़ दें
अगर हर ऐप सर्वर अपनी वॉल क्लॉक से तय करे "मैं किस मिनट में हूँ," दो सर्वर थोड़ी देर असहमत हो सकते हैं। सुरक्षित पैटर्न: रिफ़िल और विंडो आईडी के लिए स्क्रिप्ट के अंदर रेडिस सर्वर समय। शुद्ध स्थानीय डेमो के लिए मोनोटोनिक घड़ी। क्लाइंट के गढ़े टाइमस्टैम्प पर कभी भरोसा न करें।
एक एपीआई अनुरोध का लिमिटर से पूरा सफ़र
प्रिया से मिलें। लॉग-इन हैं। उनके फ़्री प्लान में प्रति मिनट १०० अनुरोध, छोटी बर्स्ट २०। सिस्टम में कई एपीआई पॉड और एक रेडिस नोटबुक है।
१. क्लाइंट अनुरोध भेजता है
ब्राउज़र या मोबाइल ऐप GET /api/weather?city=Pune कॉल करता है, प्रिया की सेशन कुकी (या एपीआई कुंजी) के साथ।
२. लोड बैलेंसर एक पॉड चुनता है
कोई भी स्वस्थ ऐप सर्वर उन्हें सँभाल सकता है। ठीक है, क्योंकि गिनती केवल उस पॉड की मेमोरी में नहीं रहेगी।
३. पहले ऑथ (आमतौर पर)
ऐप पुष्टि करता है कि यह प्रिया हैं। रेट कुंजी rl:user:priya123 जैसी बनती है, केवल आईपी नहीं। (लॉग-इन न करने वाले बॉट के लिए अलग आईपी लिमिट फिर भी रख सकते हैं।)
४. लिमिटर जाँच (बाउंसर)
ऐप (या गेटवे प्लगिन) रेडिस को कुंजी, नियम (टोकन बकेट: क्षमता २०, रिफ़िल लगभग १००/६० प्रति सेकंड) और लागत १ के साथ कॉल करता है। लुआ स्क्रिप्ट:
- वर्तमान टोकन और अंतिम रिफ़िल समय पढ़ती है,
- बीते समय के लिए टिकट जोड़ती है (क्षमता पर कैप),
- टोकन ≥ १ हो तो १ घटाकर अनुमति,
- वरना अस्वीकार और छोटा रिट्राई विलंब गिनती है।
५. अनुमति पथ
अनुरोध बिजनेस लॉजिक तक जाता है, शायद मौसम सर्विस, २०० लौटाता है। रिस्पॉन्स हेडर बता सकते हैं कितने टिकट बचे, ताकि उनका एसडीके अगले अस्वीकार से पहले धीमा हो।
६. अस्वीकार पथ
अनुरोध महँगा काम नहीं जलाता। क्लाइंट को ४२९, Retry-After संकेत, और remaining = ० मिलता है। ईमानदार क्लाइंट इंतज़ार करते हैं। दुरुपयोग करने वाले सभी पॉड पर साझा नोटबुक से ही धीमे रहते हैं।
७. ऑब्ज़र्वेबिलिटी
मेट्रिक्स अनुमति और अस्वीकार गिनते हैं। एक कुंजी पर अस्वीकार उछलें तो ऑन-कॉल पूछे: "असली आउटेज, प्रोडक्ट लिमिट बहुत तंग, या शोर वाला क्लाइंट?" इससे पहले कि कोई आँख मूँदकर संख्या बढ़ाकर "ठीक" करे।
पूरी कहानी रेट लिमिटर का सिस्टम डिज़ाइन है: नीति + एल्गोरिदम + साझा स्टोर + क्लाइंट को साफ़ प्रतिक्रिया।
बाउंसर कहाँ खड़ा हो (गेटवे की हक़ीक़त)
सीमाएँ एक से ज़्यादा जगह रख सकते हैं। कई टीमें परतें इस्तेमाल करती हैं, जैसे क्लब सुरक्षा सड़क पर, दरवाज़े पर, और वीआईपी लाउंज में।
| स्थान | ताकत | कमज़ोरी |
|---|---|---|
| सीडीएन / एज | कचरा जल्दी रोकता है | मोटी कुंजियाँ; कम बिजनेस संदर्भ |
| एपीआई गेटवे | प्रति-कुंजी प्लान, ४२९ तैयार | "यह बॉडी ५ टिकट" अजीब हो जाता है |
| सर्विस मेश (एनवॉय) | प्रति-रूट स्थानीय सीमा | केवल स्थानीय = फिर एन × सीमा |
| ऐप मिडलवेयर | यूज़र और प्रोडक्ट प्लान पूरा ज्ञान | नई सर्विस पर भूलना आसान |
| हर सर्विस में लाइब्रेरी | एक टीम के लिए तेज़ | भाषाओं में ड्रिफ्ट |
व्यावहारिक नियम: एज पर मोटी आईपी सीमाएँ, ऑथ के बाद यूज़र या प्लान सीमाएँ, महँगे म्यूटेशन पर अतिरिक्त सुरक्षा (पासवर्ड रीसेट, बल्क एक्सपोर्ट)। गेटवे ऐप सीमाएँ हटाते नहीं। वे हर जूनियर सर्विस को दिन एक को टिकट गणित फिर गढ़ने से बचाते हैं।
पदानुक्रमिक स्टैक उदाहरण:
१. प्रति आईपी (दुरुपयोग) २. प्रति यूज़र (निष्पक्षता) ३. प्रति टेनेंट रूट (प्रोडक्ट) ४. नाज़ुक निर्भरता पर ग्लोबल सर्किट
कोई भी परत ना कहे तो अस्वीकार। जहाँ हो सके सस्ती परतें पहले जाँचें।
एक डिज़ाइन जो इंटरव्यू में बचता है
पहले स्पष्ट करें:
- प्रति यूज़र प्रति मिनट १०० अनुरोध, बर्स्ट २०।
- २० ऐप इंस्टेंस पर काम करे।
- कम विलंबता पसंद; रेडिस हिचकी पर हल्का ओवरशूट ठीक।
- रिट्राई मार्गदर्शन के साथ ४२९ लौटाएँ।
प्रस्ताव:
१. कुंजी: rl:user:{userId} (रेडिस क्लस्टर हो तो हैश-टैग्ड)।
२. एल्गोरिदम: टोकन बकेट, क्षमता २०, रिफ़िल १००/६० टोकन प्रति सेकंड।
३. स्टोरेज: रेडिस प्राइमरी, एटॉमिक लुआ, रिफ़िल के लिए रेडिस समय।
४. स्थान: मोटी आईपी के लिए गेटवे; ऑथ के बाद यूज़र कोटा के लिए ऐप (या रेडिस कॉल करने वाला गेटवे प्लगिन)।
५. विफलता: सख्त स्थानीय कैप के साथ छोटा स्थानीय फेल-ओपन; रेडिस त्रुटियों पर अलार्म।
६. ऑब्ज़र्वेबिलिटी: अनुमति/अस्वीकार काउंटर, शेष हिस्टोग्राम, टॉप अस्वीकृत कुंजियाँ।
ट्रेड-ऑफ़ ज़ोर से कहें:
- फिक्स्ड विंडो सरल है लेकिन किनारे पर बर्स्टी।
- स्लाइडिंग लॉग सटीक है लेकिन भारी।
- टोकन बकेट प्रोडक्ट भाषा से मेल खाता है (बर्स्ट + सतत)।
- नेटवर्क स्प्लिट के नीचे पूर्ण वैश्विक सटीकता महँगी है; चुने विफलता मोड के साथ अनुमान सामान्य इंजीनियरिंग है।
प्रोडक्शन चेकलिस्ट
- कुंजियों में यूज़र/टेनेंट/रूट हो, केवल आईपी नहीं
- एटॉमिक अपडेट पथ (लुआ या समकक्ष), भोली रीड-देन-राइट रेस नहीं
- मल्टी-की स्क्रिप्ट हो तो क्लस्टर हैश टैग
- साझा या मोनोटोनिक घड़ी स्रोत
- ४२९ + Retry-After + शेष हेडर दस्तावेज़
- सतह के हिसाब से फेल-ओपन या फेल-क्लोज़्ड चुना
- एन इंस्टेंस और एक हॉट कुंजी से लोड टेस्ट
- डिनाई दर और रेडिस त्रुटियों के डैशबोर्ड
- लॉगिन, पासवर्ड रीसेट और महँगे म्यूटेशन के लिए अलग सीमाएँ
- "लिमिट बढ़ाओ" बनाम "शोर वाला क्लाइंट ढूँढो" के रनबुक
दोस्त के लिए सार
रेट लिमिटर आपकी एपीआई का बाउंसर है। इसलिए है ताकि एक मेहमान पूरा कमरा न खा ले (निष्पक्षता), क्लाउड बिल न फटे (लागत), और बॉट मुफ़्त में न मारें (दुरुपयोग)।
दो तस्वीरें चिपकती हैं:
१. टोकन बकेट: धीरे भरने वाली टिकट जग। बचे टिकट हों तो छोटी कतार अंदर आ सकती है। लंबे समय में रिफ़िल दर से तेज़ कभी नहीं। २. स्लाइडिंग विंडो: विंडो आगे सरकते समय केवल हाल की पट्टी गिनें। सटीक मेहमान सूची निष्पक्ष लेकिन भारी; दो मिश्रित काउंटर अक्सर काफ़ी।
हर सर्वर की निजी नोटबुक चुपचाप आपकी सीमा गुणा कर देती है। एक साझा नोटबुक (अक्सर रेडिस) असल बजट रखती है। अनुरोध का सफ़र: क्लाइंट → लोड बैलेंसर → ऑथ → साझा जाँच → असल काम में अनुमति या ४२९ "बाद में कोशिश करें।"
एक प्रोडक्शन सबक याद रहे: साझा काउंटर चतुर स्थानीय गणित को हराते हैं, और घड़ियाँ झूठ बोलेंगी जब तक आप एक समय स्रोत न थोपें। रेडिस पर टोकन बकेट या स्लाइडिंग विंडो काउंटर से शुरू करें, एज पर मोटी सीमाएँ रखें, प्रोडक्ट कोटा ऑथ के पास रखें, और संख्या बढ़ाकर "ठीक" करने से पहले अस्वीकार मापें।