# लीडर इलेक्शन और आइडेम्पोटेंसी — सिस्टम डिज़ाइन

Source: https://www.geekswithgeeks.com/hi/system-design/sd-consensus-idempotency

> कई नोड्स के बीच एक सत्य पर सहमत होना, और रिट्राई को सुरक्षित रूप से झेलना।

## लीडर की ज़रूरत क्यों

कुछ निर्णयों (कौन राइट स्वीकार करे, कौन काम सौंपे) के लिए एक समय में बिल्कुल एक नोड ज़िम्मेदार होना चाहिए। **लीडर इलेक्शन** क्लस्टर को उस नोड पर सहमत होने देता है और पता लगाता है कि उसे कब बदलना है।

## Raft, संक्षेप में

**Raft** एक कंसेंसस एल्गोरिद्म है जहाँ नोड्स यादृच्छिक टाइमआउट का उपयोग कर लीडर के लिए वोट करते हैं; सबसे अधिक वोट वाला उम्मीदवार एक टर्म जीतता है। लीडर फ़ॉलोअर्स को एक लॉग रेप्लिकेट करता है, और कोई एंट्री तभी कमिटेड मानी जाती है जब **बहुमत** के पास हो — यह नोड विफलताओं के किसी भी अल्पमत को झेल लेता है।

## आइडेम्पोटेंसी बचाती है

नेटवर्क टाइमआउट नहीं बताता कि रिक्वेस्ट पहुँची या नहीं। यदि रिट्राई और डुप्लिकेट डिलीवरी अपरिहार्य हैं, तो ऑपरेशन को **आइडेम्पोटेंट** बनाएँ: एक क्लाइंट-जनरेटेड `idempotency key` सर्वर को एक ही तार्किक रिक्वेस्ट की पुनरावृत्ति पहचानने और सुरक्षित रूप से अनदेखा करने देती है।

**Quiz:** Raft में, लॉग एंट्री कब कमिटेड मानी जाती है?

- [ ] जैसे ही लीडर इसे लिखता है
- [x] एक बार जब बहुमत नोड्स ने इसे रेप्लिकेट कर लिया हो
- [ ] एक बार जब हर नोड ने इसे रेप्लिकेट कर लिया हो

*Answer:* एक बार जब बहुमत नोड्स ने इसे रेप्लिकेट कर लिया हो. बहुमत (कोरम) कमिटमेंट Raft को सही बने रहते हुए नोड विफलताओं के अल्पमत को सहने देता है।