System Design Interview: एक Distributed Message Queue डिज़ाइन करें

समस्या और लागू परिदृश्य

एकाधिक उत्पाद टीमों द्वारा साझा की जाने वाली एक वितरित मैसेज कतार (distributed message queue) डिज़ाइन करें। स्थिर इनग्रेस (steady ingress) औसतन 1 KB प्रत्येक के साथ प्रति सेकंड 1 मिलियन मैसेजेस है, और ट्रैफ़िक पीक 15 मिनट के लिए प्रति सेकंड 3 मिलियन मैसेजेस को बनाए रख सकता है। मैसेजेस को डिफ़ॉल्ट रूप से 24 घंटे के लिए बनाए रखा जाता है। प्रोड्यूसर्स बैचों में पब्लिश करते हैं। कंज्यूमर्स ग्रुप्स के रूप में पुल (pull) करते हैं, ऑफसेट्स कमिट करते हैं, और प्रतिधारण (retention) सीमा के भीतर रिप्ले करते हैं। समान व्यावसायिक कुंजी (business key) वाले मैसेजेस के लिए स्थानीय ऑर्डरिंग की आवश्यकता होती है, जबकि विभिन्न कुंजियाँ समानांतर में चल सकती हैं। साधारण मैसेजेस एट-लीस्ट-वंस डिलीवरी का उपयोग करते हैं, और पब्लिश एक्नॉलेजमेंट का p99 लक्ष्य 50 मिलीसेकंड से कम है। प्रत्येक पार्टीशन में तीन उपलब्धता क्षेत्रों (availability zones) में तीन रेप्लिका होते हैं; एक ज़ोन खोने पर भी एक्नॉलेज किए गए मैसेज नहीं खोने चाहिए।

अधिकांश मैसेज छोटे होते हैं, लेकिन API 100 MB तक के व्यावसायिक पेलोड्स की अनुमति देता है। एक बड़े पेलोड को ब्रोकर लॉग्स, रेप्लिका ट्रांसफ़र और कंज्यूमर बफ़र्स से बार-बार नहीं गुजरना चाहिए। इस डिज़ाइन में यह पहले ऑब्जेक्ट स्टोरेज में प्रवेश करता है, जबकि कतार केवल एक अपरिवर्तनीय संदर्भ (immutable reference), साइज़ और चेकसम को स्टोर करती है। थ्रूपुट, लेटेंसी, रिटेंशन, थ्रेशोल्ड और रेप्लिका गणनाएँ इंटरव्यू धारणाएँ हैं जिन्हें लक्षित हार्डवेयर पर बेंचमार्किंग की आवश्यकता होती है। वे उत्पाद के दावे नहीं हैं।

मई 2026 में प्रकाशित एक चीनी सिस्टम-डिज़ाइन लेख सीधे तौर पर प्रतिदिन दसियों अरबों मैसेजेस को प्रोसेस करने वाली और दस लाख-QPS पीक वाली कतार पर चर्चा करता है। जून 2026 में अपडेट किया गया एक PracHub प्रॉम्प्ट उम्मीदवारों से APIs, कंज्यूमर ग्रुप्स, ऑफसेट्स, पार्टीशन्स, रेप्लिका, बड़े पेलोड्स और मल्टी-टेनेंट आइसोलेशन को कवर करने के लिए कहता है। साथ मिलकर वे वर्तमान में सत्यापन योग्य सिस्टम-डिज़ाइन प्रॉम्प्ट स्थापित करते हैं। केवल एक पेज कंपनी एट्रिब्यूशन का दावा करता है, इसलिए यह लेख कंपनी को अनसेट छोड़ता है।

इंटरव्यूअर्स क्या मूल्यांकन करते हैं

पहला, क्या उम्मीदवार डिलीवरी कॉन्ट्रैक्ट को परिभाषित करता है? एक सफल पब्लिश, ड्यूरेबल ब्रोकर स्टोरेज, कंज्यूमर को मैसेज डिलीवरी, व्यावसायिक साइड इफ़ेक्ट का पूरा होना, और एक ऑफसेट कमिट पाँच अलग-अलग सीमाएँ (boundaries) हैं। इन सभी को "मैसेज सफलता" कहना दो विफलता विंडो छुपाता है: एक प्रोड्यूसर एक्नॉलेजमेंट खोने के बाद पब्लिश दोहरा सकता है, और एक कंज्यूमर साइड इफ़ेक्ट पूरा करने के बाद लेकिन ऑफसेट कमिट करने से पहले क्रैश होने पर काम दोहरा सकता है।

दूसरा, क्या पार्टीशनिंग, ऑर्डरिंग और स्केलिंग एक ही तर्क का पालन करते हैं? एक पार्टीशन को एक कुंजी भेजने से उस कुंजी का लॉग क्रम सुरक्षित रहता है। वही पार्टीशन राइट थ्रूपुट और कंज्यूमर-ग्रुप पैरेललिज्म दोनों को सीमित करता है। अधिक पार्टीशन्स समानांतर स्लॉट जोड़ते हैं, लेकिन वे लगातार ओवरलोड होने वाली हॉट की को विभाजित नहीं करते हैं या वैश्विक ऑर्डरिंग नहीं बनाते हैं।

तीसरा, क्या रेप्लिका एक्नॉलेजमेंट नियम विफलता से बचता है? एक मजबूत उत्तर बताता है कि प्रोड्यूसर को कब एक्नॉलेज किया जा सकता है, कौन से रेप्लिका एक नया लीडर बनने के योग्य हैं, और एक इपॉक (epoch) पुनर्प्राप्त पुराने लीडर को कैसे बाड़ (fence) लगाता है। यह कहना कि "तीन रेप्लिका स्वचालित रूप से फ़ेलओवर हो जाते हैं" यह साबित नहीं करता है कि एक्नॉलेज किए गए रिकॉर्ड्स बचते हैं।

चौथा, क्या कंज्यूमर ऑफसेट्स व्यावसायिक परिणामों से जुड़े हैं? प्रोसेसिंग से पहले कमिट करने से कोई व्यावसायिक प्रभाव छूट सकता है। कमिट करने से पहले प्रोसेसिंग करने से क्रैश के बाद इसे रिप्ले किया जा सकता है। एट-लीस्ट-वंस दूसरी विंडो चुनता है, फिर एक स्थिर मैसेज ID, व्यावसायिक इडेम्पोटेंसी कुंजी, अद्वितीय बाधा (unique constraint), या संस्करण स्थिति के साथ दोहराव को अवशोषित करता है। एक ब्रोकर ट्रांजेक्शन केवल उस ट्रांजेक्शन में भाग लेने वाले संसाधनों को कवर करता है; यह किसी बाहरी भुगतान सेवा, ईमेल प्रदाता, या डेटाबेस को स्वचालित रूप से सटीक रूप से एक बार (exactly-once) प्रभाव नहीं देता है।

अंत में, क्या कतार दबाव में इन सीमाओं को सुरक्षित रख सकती है? उम्मीदवार को 24-घंटे के स्टोरेज और बर्स्ट बैकलॉग की गणना करनी चाहिए, बड़े मैसेजेस, हॉट पार्टीशन्स, धीमे कंज्यूमर्स, पॉइज़न मैसेजेस, भरे हुए डिस्क्स और अत्यधिक शोर करने वाले किरायेदारों (noisy tenants) को संभालना चाहिए, फिर यह साबित करने के लिए विफलताएँ इंजेक्ट करनी चाहिए कि एक्नॉलेज किए गए मैसेज खोए नहीं हैं, अनकमिटेड कार्य नहीं छोड़ा गया है, और पुराने मालिक ऑफसेट को आगे नहीं बढ़ा सकते हैं।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्या यह एक रिटेन्ड लॉग है या क्लेम-एंड-डिलीट वर्क कतार है? यह डिज़ाइन एक रिटेन्ड लॉग चुनता है क्योंकि एकाधिक कंज्यूमर ग्रुप्स और रिप्ले की आवश्यकता होती है। यदि बिल्कुल एक वर्कर प्रत्येक कार्य का दावा करता है और ऐतिहासिक रिप्ले अनावश्यक है, तो विजिबिलिटी टाइमआउट वाली लीज कतार सरल है।
• ऑर्डरिंग का दायरा क्या है? ऑर्डरिंग एक टॉपिक पार्टीशन के भीतर अपेंड ऑर्डर को कवर करती है, जिसमें एक व्यावसायिक कुंजी एक पार्टीशन पर पिन की जाती है। कुंजियों, पार्टीशन्स या टॉपिक्स में कोई वैश्विक क्रम नहीं है। वैश्विक क्रम थ्रूपुट को एक सीरियल लॉग तक कम कर देगा।
• पब्लिश एक्नॉलेजमेंट का क्या मतलब है? तीन में से दो रेप्लिका ने रिकॉर्ड को ड्यूरेबली स्टोर कर लिया है, और कंट्रोल प्लेन अभी भी वर्तमान लीडर इपॉक को पहचानता है। एक अत्यधिक ड्यूरेबल टॉपिक दो से कम रेप्लिका उपलब्ध होने पर राइट्स को अस्वीकार करता है।
• कंजम्पशन सिमेंटिक क्या है? डिफ़ॉल्ट कम से कम एक बार (at least once) है: सफलतापूर्वक प्रोसेस करें, फिर अगला ऑफसेट कमिट करें। बाहरी साइड इफेक्ट्स के लिए इडेम्पोटेंसी या समाधान (reconciliation) की आवश्यकता होती है। केवल एक कम-मूल्य वाला वर्कलोड जो नुकसान की अनुमति देता है लेकिन डुप्लिकेट को मना करता है, उसे पहले कमिट करना चाहिए।
• क्या कंज्यूमर्स को मनमाने रिप्ले की आवश्यकता है? एक ग्रुप 24-घंटे की रिटेंशन विंडो के भीतर ऑफसेट या टाइमस्टैम्प द्वारा रीसेट कर सकता है। रिटेंशन से परे इसे एक आर्काइव से पुनर्स्थापित करना चाहिए, या आर्काइव न होने पर स्पष्ट रूप से विफल होना चाहिए।
• क्या पॉइज़न मैसेजेस को छोड़ा जा सकता है? साधारण टॉपिक्स बाउंडेड रीप्रयासों के बाद किसी मैसेज को डेड-लेटर टॉपिक में ले जा सकते हैं। एक सख्त कुंजी-ऑर्डर्ड टॉपिक इसे मुफ्त में नहीं छोड़ सकता; कुंजी या पार्टीशन को रोकें और इसे सुधारें, अन्यथा बाद के मैसेज विफलता को पार कर सकते हैं।
• क्या 100 MB पेलोड इनलाइन होना चाहिए? नहीं। यह डिज़ाइन 256 KiB तक के इनलाइन पेलोड्स को मानता है और उस सीमा से ऊपर ऑब्जेक्ट संदर्भों का उपयोग करता है। बेंचमार्किंग और लागत सीमा निर्धारित करते हैं; 100 MB ऑब्जेक्ट-पेलोड सीमा है।
• क्रॉस-रीजन आवश्यकता क्या है? प्राथमिक डिज़ाइन तीन उपलब्धता क्षेत्रों में एक क्षेत्र (region) है। एसिंक्रोनस क्रॉस-रीजन डिजास्टर रिकवरी शून्य डेटा हानि और स्थानीय राइट लेटेंसी दोनों का वादा नहीं कर सकती है। एक शून्य-RPO क्रॉस-रीजन आवश्यकता एक्नॉलेजमेंट पाथ और लेटेंसी बजट को बदल देती है।
• टेनेंट आइसोलेशन कितना मजबूत है? ब्रोकर्स डिफ़ॉल्ट रूप से साझा किए जाते हैं, जिसमें प्रति-किरायेदार इनग्रेस, एग्रेस, स्टोरेज, पार्टीशन और कनेक्शन सीमाएँ होती हैं। बहुत बड़े या विनियमित किरायेदार समान कंट्रोल प्लेन और प्रोटोकॉल के तहत एक समर्पित ब्रोकर पूल का उपयोग कर सकते हैं।

30-सेकंड उत्तर ढाँचा

"मैं इसे एक रिटेन्ड, रिप्ले करने योग्य पार्टीशन्ड लॉग के रूप में मॉडल करूँगा। प्रोड्यूसर व्यावसायिक कुंजी द्वारा एक पार्टीशन लीडर को रूट करता है, राइट्स को बैच करता है, और अलग-अलग उपलब्धता क्षेत्रों में दो रेप्लिका द्वारा बैच को बनाए रखने के बाद ही एक एक्नॉलेजमेंट प्राप्त करता है। यह प्रति-कुंजी क्रम देता है, वैश्विक क्रम नहीं। एक कंज्यूमर ग्रुप विशेष रूप से पार्टीशन्स का मालिक होता है, एक इडेम्पोटेंट व्यावसायिक राइट पूरा करता है, और फिर अगला ऑफसेट कमिट करता है, इसलिए डिलीवरी कम से कम एक बार होती है और बाहरी प्रभाव मैसेज ID द्वारा डिडुप्लिकेट होते हैं। स्थिर इनग्रेस लगभग 1 GB/s और तार्किक रूप से प्रति दिन 86.4 TB है, या तीन रेप्लिका के साथ 259.2 TB है। 15 मिनट का तीन गुना पीक लगभग 1.8 TB अतिरिक्त बैकलॉग बनाता है यदि कंज्यूमर्स स्थिर दर बनाए रखते हैं। 256 KiB से ऊपर के पेलोड्स ऑब्जेक्ट स्टोरेज में जाते हैं और कतार एक संदर्भ और चेकसम ले जाती है। मैं किरायेदार कोटा, फेयर शेड्यूलिंग, लैग अलर्ट्स, लीडर विफलता, खोए हुए एक्नॉलेजमेंट और कंज्यूमर-क्रैश परीक्षणों के साथ सीमाओं को साबित करूँगा।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: घटकों से पहले APIs और इनवेरिएंट्स लिखें।

आवश्यक सतह टॉपिक्स, पब्लिशिंग, फेचिंग, कमिटिंग और ऑफसेट्स को रीसेट करने को कवर करती है:

POST /v1/topics
POST /v1/topics/{topic}/messages:publish
POST /v1/groups/{group}/messages:fetch
POST /v1/groups/{group}/offsets:commit
POST /v1/groups/{group}/offsets:reset

एक पब्लिश रिक्वेस्ट एक प्रमाणित किरायेदार संदर्भ, टॉपिक, वैकल्पिक message_key, स्थिर message_id, पेलोड या ऑब्जेक्ट संदर्भ, प्रोड्यूसर इपॉक, और प्रति-पार्टीशन अनुक्रम ले जाती है। बैच प्रतिक्रिया प्रत्येक मैसेज के पार्टीशन, ऑफसेट और कमिट स्थिति को लौटाती है। फेच ग्रुप, पार्टीशन-स्वामित्व जेनरेशन, शुरुआती ऑफसेट, अधिकतम बाइट्स, और लॉन्ग-पोल अवधि ले जाता है। कमिट पढ़े जाने वाले अगले रिकॉर्ड का ऑफसेट लिखता है।

डिज़ाइन चार इनवेरिएंट्स को सुरक्षित रखता है: एक एक्नॉलेज किया गया रिकॉर्ड एक उपलब्धता-क्षेत्र विफलता के बाद पठनीय रहता है; कंज्यूमर्स केवल एक कमिटेड प्रीफ़िक्स देखते हैं; ऑफसेट्स लीडर इपॉक के भीतर मोनोटोनिक रूप से बढ़ते हैं; और एक समाप्त जेनरेशन वाला कंज्यूमर ऑफसेट्स को कमिट नहीं कर सकता है या परिणाम लिखना जारी नहीं रख सकता है। API-स्तरीय message_id व्यावसायिक डिडुप्लिकेशन का समर्थन करता है। producer_id + epoch + sequence ब्रोकर को उसी पब्लिश के रीप्रयास को पहचानने देता है।

चरण 2: कंट्रोल प्लेन को डेटा प्लेन से अलग करें।

Control plane: tenants and ACLs, topic configuration, partition placement,
               replica membership, leader epochs, quotas

Data plane:
Producer -> metadata cache -> partition leader -> follower replicas
Consumer group -> group coordinator -> partition leaders -> business sink

एक छोटा सर्वसम्मति-समर्थित (consensus-backed) क्लस्टर टॉपिक और पार्टीशन मेटाडेटा संग्रहीत करता है और प्रत्येक लीडर कार्यकाल को मोनोटोनिक रूप से बढ़ते इपॉक को निर्दिष्ट करता है। यह मैसेज बॉडीज को नहीं ले जाता है। ब्रोकर्स रिकॉर्ड्स को अपेंड, रेप्लिकेट, रीड और रिटेन करते हैं। क्लाइंट्स पार्टीशन लीडर्स को कैश करते हैं और बासी-इपॉक या नॉट-लीडर प्रतिक्रिया के बाद मेटाडेटा को रीफ्रेश करते हैं। मैसेज थ्रूपुट एक केंद्रीय प्रॉक्सी से बचता है, जबकि मौजूदा पार्टीशन्स कंट्रोल-प्लेन आउटेज के दौरान एक सीमित लीज के लिए जारी रह सकते हैं। टॉपिक निर्माण और पार्टीशन आंदोलन रुक सकते हैं; बासी मेटाडेटा को कभी भी मनमाना लीडर नहीं चुनना चाहिए।

चरण 3: थ्रूपुट, रिप्ले और स्थानीय ऑर्डरिंग के लिए पार्टीशन्ड लॉग्स का उपयोग करें।

प्रत्येक पार्टीशन अपेंड-ओनली सेगमेंट्स का एक सेट है जिनके रिकॉर्ड्स में शामिल हैं:

MessageEnvelope {
  tenant_id, topic, partition, offset
  message_id, message_key, producer_id, producer_epoch, sequence
  created_at, headers, payload_or_ref, payload_size, checksum
}

सक्रिय सेगमेंट अनुक्रमिक अपेंड्स प्राप्त करता है। एक स्पार्स ऑफसेट इंडेक्स रीड्स का पता लगाता है, और बंद सेगमेंट समय या साइज़ के अनुसार रोल होते हैं। कंज्यूमर्स ऑफसेट द्वारा बैच प्राप्त करते हैं, जिससे अनुक्रमिक I/O, पेज-कैश उपयोग और बैच नेटवर्क ट्रांसफर की अनुमति मिलती है। रिटेंशन 24 घंटों के बाद पूरे सेगमेंट्स को हटा देता है। वैध रिप्ले या टियर-स्टोरेज अपलोड के तहत एक सेगमेंट एक संदर्भ रखता है ताकि विलोपन पाठक के साथ प्रतिस्पर्धा (race) न कर सके।

राउटिंग हैश में विश्वसनीय टेनेंट, टॉपिक और व्यावसायिक कुंजी शामिल हैं। एक ही कुंजी वाले रिकॉर्ड एक पार्टीशन पर रहते हैं; अनकीड रिकॉर्ड्स राउंड-रॉबिन या स्टिकी-बैच असाइनमेंट का उपयोग कर सकते हैं। केवल टेनेंट राउटिंग एक बड़े किरायेदार को हॉट बनाती है, जबकि पूरी तरह से यादृच्छिक राउटिंग कुंजी क्रम खो देती है। पार्टीशन्स जोड़ने से भविष्य के रिकॉर्ड प्रभावित होते हैं। एक बदला हुआ मॉड्यूलो एक कुंजी को पुराने और नए दोनों पार्टीशन्स पर रख सकता है। जब स्थिर क्रम मायने रखता है, तो वर्चुअल शार्ड्स को भौतिक पार्टीशन्स में मैप करें; स्थानांतरण के दौरान वर्चुअल शार्ड को रोकें, कटओवर ऑफसेट रिकॉर्ड करें, पुराने मालिक को ड्रेन करें, और एक नए इपॉक के तहत फिर से शुरू करें।

चरण 4: रेप्लिकेशन और लीडर चुनाव को कमिट की एक परिभाषा दें।

प्रत्येक पार्टीशन के तीन उपलब्धता क्षेत्रों में तीन रेप्लिका होते हैं। लीडर ऑफसेट्स प्रदान करता है, ड्यूरेबली रूप से एक बैच जोड़ता है, और समानांतर में इसे रेप्लिकेट करता है। एक बार जब किन्हीं दो रेप्लिका ने बैच को बनाए रखा है, तो commit_watermark आगे बढ़ता है और प्रोड्यूसर को एक्नॉलेज किया जाता है। कंज्यूमर्स केवल उस वॉटरमार्क से नीचे के ऑफसेट्स पढ़ते हैं। लीडर की विफलता पर, कंट्रोल प्लेन केवल कमिटेड प्रीफ़िक्स वाले रेप्लिका का चयन करता है और इपॉक को बढ़ाता है। एक पुनर्प्राप्त पुराना लीडर अपनी अनकमिटेड टेल को छोटा (truncate) करता है और सेवा देने से पहले बराबरी करता है; इसके पुराने इपॉक को ले जाने वाले अनुरोधों को अस्वीकार कर दिया जाता है।

यह नीति एक उपलब्धता-क्षेत्र की विफलता को सहन करती है। दो रेप्लिका शेष रहने के साथ, दोनों को एक्नॉलेज करना होगा, इसलिए लेटेंसी और क्षमता ख़राब हो जाती है। यदि कोई भी शेष रेप्लिका विफल हो जाता है, तो एक अत्यधिक ड्यूरेबल टॉपिक रेप्लिकेशन बहाल होने तक राइट्स को एक्नॉलेज करना बंद कर देता है। उपलब्धता में सुधार के लिए एक पुराने रेप्लिका को चुनना नो-लॉस वादे का उल्लंघन करेगा। नेटवर्क पार्टीशन के दौरान, केवल कमिट बहुमत वाले पक्ष को लिखने की अनुमति है; दूसरा पक्ष बाड़ (fenced) लगा दिया जाता है।

एक प्रोड्यूसर तब पुनः प्रयास करता है जब रिकॉर्ड कमिट हो गया था लेकिन एक्नॉलेजमेंट प्रतिक्रिया खो गई थी। ब्रोकर प्रोड्यूसर इपॉक और मोनोटोनिक अनुक्रम का उपयोग करके पार्टीशन के भीतर डिडुप्लिकेट करता है और मूल ऑफसेट लौटाता है। पुराने इपॉक वाले जॉम्बी प्रोड्यूसर को अस्वीकार कर दिया जाता है। यह पब्लिश रीप्रयासों के कारण होने वाले लॉग डुप्लिकेट को हटा देता है। यह दो अलग-अलग व्यावसायिक अनुरोधों को संयोजित नहीं करता है जिन्होंने अलग-अलग IDs का उपयोग किया था, या किसी कंज्यूमर के बाहरी साइड इफ़ेक्ट को डिडुप्लिकेट नहीं करता है।

चरण 5: ग्रुप स्वामित्व और ऑफसेट्स को व्यावसायिक परिणाम से कनेक्ट करें।

कंज्यूमर ग्रुप के भीतर, एक समय में एक सदस्य के पास पार्टीशन का स्वामित्व होता है। ग्रुप समन्वयक सदस्यों, लीज, जेनरेशन्स और असाइनमेंट्स का प्रबंधन करता है। एक टाइमआउट या स्केलिंग इवेंट एक नई जेनरेशन बनाता है, और पुराने सदस्य से फेच या कमिट को अस्वीकार कर दिया जाता है। वृद्धिशील पुनर्संतुलन (incremental rebalancing) केवल आवश्यक पार्टीशन्स को स्थानांतरित करता है और ग्रुप-व्यापी ठहराव को कम करता है, लेकिन कंज्यूमर को अभी भी स्वामित्व रद्द होने से पहले फेचिंग बंद करनी चाहिए और समाप्त कार्य को कमिट करना चाहिए।

डिफ़ॉल्ट क्रम एक बैच लाना, एक इडेम्पोटेंट व्यावसायिक राइट निष्पादित करना, फिर अगला ऑफसेट कमिट करना है। यदि कंज्यूमर व्यावसायिक कमिट के बाद और ऑफसेट कमिट से पहले क्रैश हो जाता है, तो नया मालिक पूर्ण रिकॉर्ड्स को रिप्ले करता है, जो कम से कम एक बार डिलीवरी बनाता है। एक स्थिर message_id एक अद्वितीय बाधा या प्रोसेस किए गए मैसेज रिकॉर्ड का समर्थन कर सकता है, या व्यावसायिक स्थिति के समान डेटाबेस ट्रांजेक्शन में कमिट किया जा सकता है। यदि आउटपुट उसी मैसेजिंग सिस्टम में लौटता है, तो आउटपुट रिकॉर्ड और इनपुट ऑफसेट एक ब्रोकर ट्रांजेक्शन साझा कर सकते हैं। एक बाहरी डेटाबेस, भुगतान, या ईमेल प्रदाता को अभी भी इडेम्पोटेंसी, स्थिति लुकअप, या समाधान की आवश्यकता होती है।

ऑफसेट्स (tenant, group, topic, partition) के तहत एक रेप्लिकेटेड मेटाडेटा लॉग में संग्रहीत होते हैं और जेनरेशन ले जाते हैं। निगरानी में log_end_offset - committed_offset और सबसे पुराने अनप्रोसेस्ड मैसेज की आयु दोनों शामिल हैं। अकेले मैसेज की संख्या परिवर्तनीय रिकॉर्ड आकारों के साथ बैकलॉग को गलत बताती है, इसलिए सिस्टम वर्तमान शुद्ध कंजम्पशन दर पर लैग बाइट्स और कैच-अप समय की भी रिपोर्ट करता है।

चरण 6: रीप्रयासों, डेड लेटर्स और ऑर्डरिंग के बीच संघर्ष बताएं।

क्षणिक नेटवर्क और थ्रॉटलिंग विफलताएं जिटर (jitter) के साथ विलंबित रीप्रयास टॉपिक में प्रवेश करती हैं। नियतात्मक (deterministic) स्कीमा, अनुमति, या व्यावसायिक-सत्यापन विफलताओं का आँख बंद करके पुनः प्रयास नहीं किया जाना चाहिए। एक रीप्रयास मूल message_id, स्रोत टॉपिक, पार्टीशन, ऑफसेट, पहली बार देखे जाने का समय, प्रयास गणना, और त्रुटि वर्ग को संरक्षित करता है। प्रयास या व्यावसायिक-समय सीमा के बाद, यह एक डेड-लेटर टॉपिक पर जाता है, एक चेतावनी उठाता है, और नियंत्रित रीड्राइव की अनुमति देता है। रीड्राइव मूल ID रखता है ताकि यह इडेम्पोटेंसी को बायपास न कर सके।

विफल रिकॉर्ड को एक तरफ ले जाने से बाद के रिकॉर्ड पहले समाप्त हो जाते हैं, जो सख्त प्रति-कुंजी क्रम के साथ संघर्ष करता है। यदि ऑर्डर स्थिति को सख्ती से विकसित होना चाहिए, तो उस कुंजी को रोकें और उसके बाद के रिकॉर्ड्स को एक अलग ऑर्डर्ड लेन में बफ़र करें, फिर मरम्मत के बाद विफल ऑफसेट से फिर से शुरू करें। पूरे पार्टीशन को रोकना सरल है लेकिन इसका ब्लास्ट रेडियस बड़ा है। यदि व्यवसाय संस्करण द्वारा अभिसरण (convergence by version) स्वीकार करता है, तो बाद के रिकॉर्ड आगे बढ़ सकते हैं और सिंक पुराने संस्करणों को अस्वीकार कर देता है। टॉपिक कॉन्ट्रैक्ट को चुनना होगा; यह "पॉइज़न मैसेज कभी ब्लॉक नहीं होते" और "मैसेज कभी एक दूसरे को पार नहीं करते" दोनों का वादा नहीं कर सकता।

चरण 7: बड़े मैसेजेस को ऑब्जेक्ट संदर्भों के पीछे रखें और कचरा-संग्रह (garbage-collection) दौड़ को बंद करें।

यह डिज़ाइन इनलाइन सीमा के रूप में 256 KiB सेट करता है। एक बड़ा पेलोड अपने साइज़, सामग्री हैश, और एन्क्रिप्शन मेटाडेटा के साथ एक अपरिवर्तनीय ऑब्जेक्ट लिखने के लिए अल्पकालिक अपलोड क्रेडेंशियल्स का उपयोग करता है। अपलोड सफल होने के बाद ही प्रोड्यूसर संदर्भ पब्लिश करता है। एक कंज्यूमर ऑब्जेक्ट को पढ़ता है और हैश की पुष्टि करता है। ब्रोकर रेप्लिका केवल छोटे लिफाफे को कॉपी करते हैं, इसलिए 100 MB का रिकॉर्ड नेटवर्क बफ़र्स, रेप्लिकेशन बैचों या कंज्यूमर मेमोरी पर एकाधिकार नहीं कर सकता है।

एक सफल अपलोड जिसका संदर्भ कभी पब्लिश नहीं किया गया था वह एक अनाथ (orphan) है और अपलोड-सत्र TTL के साथ समाप्त हो जाता है। एक बार संदर्भ कमिट हो जाने के बाद, ऑब्जेक्ट रिटेंशन में मैसेज रिटेंशन, वैध रिप्ले, डेड लेटर्स और एक सुरक्षा मार्जिन शामिल होना चाहिए। एक विलोपन कार्य पहले संरक्षित संदर्भों की जांच करता है और एक ग्रेस अवधि के बाद हटा देता है। जब ऑब्जेक्ट रीड्स विफल हो जाते हैं, तो कंजम्पशन अनकमिटेड रहता है और पुनः प्रयास करता है; पहले एक्नॉलेज करने से बॉडी स्थायी रूप से गायब हो सकती है। बड़े पेलोड्स को अलग-अलग प्रति-किरायेदार बाइट-दर, समवर्ती-डाउनलोड और स्टोरेज कोटा प्राप्त होते हैं क्योंकि मैसेज-काउंट थ्रॉटलिंग उनकी गलत कीमत लगाती है।

चरण 8: क्षमता से पार्टीशन्स, डिस्क, और कैच-अप हेडरूम प्राप्त करें।

दशमलव 1 KB का उपयोग करते हुए, स्थिर तार्किक इनग्रेस है:

1,000,000 messages/s × 1,000 bytes = 1 GB/s
1 GB/s × 86,400 s = 86.4 TB/day
Lower bound for three replica writes = 86.4 × 3 = 259.2 TB/day

15 मिनट के पीक के दौरान कुल इनग्रेस 3 GB/s × 900 = 2.7 TB है। यदि कंज्यूमर्स केवल स्थिर 1 GB/s बनाए रखते हैं, तो अतिरिक्त बैकलॉग है:

(3 GB/s - 1 GB/s) × 900 s = 1.8 TB

पीक के बाद, मान लीजिए कि कंज्यूमर्स 1.5 GB/s बनाए रखते हैं जबकि नया इनग्रेस 1 GB/s रहता है। शुद्ध कैच-अप दर 0.5 GB/s है, इसलिए 1.8 TB को सिद्धांत रूप में ड्रेन होने में 3,600 सेकंड, या लगभग एक घंटा लगता है। रेप्लिका रिकवरी, बैच ओवरहेड, कम्प्रेशन, इंडेक्स, फाइलसिस्टम रिजर्व और बड़े-मैसेज ऑब्जेक्ट स्टोरेज क्षमता जोड़ते हैं, इसलिए ये निचली सीमाएं हैं।

पार्टीशन गणना बाइट्स और मैसेजेस दोनों द्वारा सीमित है। मान लीजिए कि तीन रेप्लिका और लक्षित p99 के साथ एक बेंचमार्क पाता है कि एक पार्टीशन 40 MB/s और प्रति सेकंड 40,000 मैसेजेस को बनाए रखता है। दोनों पीक आयामों के लिए कम से कम 75 पार्टीशन्स की आवश्यकता होती है। विफलता और पुनर्संतुलन के लिए 50% हेडरूम जोड़ने पर लगभग 113 प्राप्त होता है, इसलिए 128 एक व्यावहारिक विकल्प है। वह प्रति-पार्टीशन परिणाम एक इंटरव्यू बेंचमार्क धारणा है। विभिन्न हार्डवेयर, बैचों, एक्नॉलेजमेंट्स, या रिकॉर्ड आकारों के लिए एक नए परीक्षण की आवश्यकता होती है; 128 कोई सार्वभौमिक उत्तर नहीं है।

चरण 9: बैकप्रेशर, टेनेंट आइसोलेशन और सत्यापन योग्य संचालन लागू करें।

कंज्यूमर्स लॉन्ग पोलिंग का उपयोग करते हैं और max_bytes और इन-फ़्लाइट बैच सीमाओं के साथ अपनी दर को नियंत्रित करते हैं। जैसे-जैसे ब्रोकर डिस्क वॉटरमार्क बढ़ते हैं, सिस्टम पहले नए पार्टीशन निर्माण को रोकता है, कम प्राथमिकता वाले किरायेदारों के लिए बर्स्ट भत्ते को कम करता है, फिर पुनः प्रयास करने योग्य सिग्नल के साथ ओवर-कोटा पब्लिश को अस्वीकार करता है। अनबाउंडेड मेमोरी कतारें और रीप्रयास कंजेशन को प्रक्रिया विफलता में बदल देते हैं। प्रोड्यूसर्स बाउंडेड बैच बफ़र्स, समय सीमा, और जिटरेड बैकऑफ़ का उपयोग करते हैं ताकि ब्रोकर आउटेज सिंक्रनाइज़ किए गए रीप्रयास तूफानों का निर्माण न कर सके।

किरायेदार की पहचान क्रेडेंशियल्स से आती है, कभी भी मैसेज बॉडी से नहीं। इनग्रेस मैसेज और बाइट दर द्वारा सीमित है। एग्रेस फेच बाइट्स और रिक्वेस्ट CPU द्वारा उचित रूप से निर्धारित (fair-scheduled) है। स्टोरेज, पार्टीशन्स, कंज्यूमर ग्रुप्स, कनेक्शन्स, इन-फ़्लाइट रिक्वेस्ट्स, और बड़े ऑब्जेक्ट्स की भी सीमाएं हैं। प्लेसमेंट एक किरायेदार के रेप्लिका या हॉट पार्टीशन्स को कुछ ब्रोकर्स पर केंद्रित करने से बचाता है। बहुत बड़े किरायेदार समर्पित पूलों में चले जाते हैं, जबकि साझा पूल अभी भी प्रति किरायेदार अस्वीकृति को मापते और रिपोर्ट करते हैं।

प्रमुख मेट्रिक्स में पब्लिश एक्नॉलेजमेंट p50/p95/p99, त्रुटियाँ और अज्ञात परिणाम; प्रति-पार्टीशन इनग्रेस बाइट्स, लीडर और फॉलोअर लैग, commit_watermark, डिस्क वॉटरमार्क, और हॉट कीज़; कंज्यूमर-ग्रुप कमिटेड ऑफसेट्स, कंज्यूमर लैग, सबसे पुरानी आयु, रीबैलेंस, रीप्रयास, और डेड लेटर्स; ऑब्जेक्ट अनाथ और रीड विफलताएं; और प्रति-किरायेदार थ्रॉटलिंग और निष्पक्षता शामिल हैं। एक एंड-टू-एंड कैनरी एक स्थिर ID पब्लिश करती है, एक इडेम्पोटेंट व्यावसायिक परिणाम कमिट करती है, फिर अपना ऑफसेट कमिट करती है और ब्रोकर, ग्रुप और व्यावसायिक स्थितियों का समाधान करती है।

फॉल्ट मैट्रिक्स में रेप्लिकेशन से पहले, कमिट के बाद, और एक्नॉलेजमेंट लौटाने से पहले लीडर क्रैश; एक उपलब्धता-क्षेत्र की हानि; नेटवर्क पार्टीशन; भरी हुई डिस्क; बासी-लीडर रिकवरी; हॉट की; 15 मिनट का तीन गुना पीक; अपने व्यावसायिक कमिट से पहले और बाद में कंज्यूमर क्रैश; रीबैलेंस के दौरान बासी कमिट्स; पॉइज़न मैसेजेस; अपलोड सफलता के बाद पब्लिश विफलता; ऑब्जेक्ट-रीड विफलता; और डेड-लेटर रीड्राइव शामिल हैं। स्वीकृति यह दावा करती है कि एक्नॉलेज किए गए रिकॉर्ड्स बचते हैं, अनकमिटेड कार्य नहीं छोड़ा जाता है, कुंजी क्रम टॉपिक कॉन्ट्रैक्ट का पालन करता है, बासी जेनरेशन्स ऑफसेट्स को आगे नहीं बढ़ा सकती हैं, और प्रत्येक डुप्लिकेट, अस्वीकृति, या ड्रॉप में एक एट्रिब्यूटेबल मेट्रिक होता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं पहले पुष्टि करूँगा कि यह एकाधिक कंज्यूमर ग्रुप्स और 24-घंटे के रिप्ले की आवश्यकता वाली एक रिटेन्ड-लॉग सेवा है। एक टॉपिक पार्टीशन्स में विभाजित है, और एक ही व्यावसायिक कुंजी एक पार्टीशन पर रहती है। इसलिए ऑर्डरिंग एक कुंजी और पार्टीशन को कवर करती है, जबकि विभिन्न पार्टीशन्स समानांतर में चलते हैं। प्रोड्यूसर्स कंट्रोल प्लेन से लीडर मेटाडेटा प्राप्त करते हैं और सीधे बैच लिखते हैं। प्रत्येक पार्टीशन में उपलब्धता क्षेत्रों में तीन रेप्लिका होते हैं; केवल दो ड्यूरेबल रेप्लिका commit_watermark को आगे बढ़ाते हैं और प्रोड्यूसर को एक्नॉलेज करते हैं। एक नए लीडर में कमिटेड प्रीफ़िक्स होना चाहिए, और इपॉक्स पुराने लीडर्स और प्रोड्यूसर्स को बाड़ (fence) लगाते हैं।

स्टोरेज अपेंड-ओनली सेगमेंट्स और एक स्पार्स ऑफसेट इंडेक्स का उपयोग करता है। ग्रुप कंज्यूमर्स विशेष रूप से पार्टीशन्स के मालिक होते हैं और लॉन्ग-पोल करते हैं। कंज्यूमर अगला ऑफसेट कमिट करने से पहले एक इडेम्पोटेंट व्यावसायिक परिणाम कमिट करता है। एक क्रैश कार्य को रिप्ले कर सकता है लेकिन चुपचाप इसे छोड़ नहीं सकता। प्रोड्यूसर पक्ष पर, प्रोड्यूसर इपॉक और अनुक्रम खोए हुए एक्नॉलेजमेंट के कारण होने वाले रीप्रयासों को हटा देते हैं। कंज्यूमर पक्ष पर, एक स्थिर मैसेज ID, अद्वितीय बाधा, या संस्करण स्थिति दोहराए गए प्रभावों को अवशोषित करती है। मैं एंड-टू-एंड ब्रोकर ट्रांजेक्शन का दावा तभी करूँगा जब इनपुट ऑफसेट और आउटपुट दोनों उस ब्रोकर ट्रांजेक्शन में रहें; बाहरी प्रणालियों को अभी भी इडेम्पोटेंसी या समाधान की आवश्यकता होती है।

स्थिर क्षमता प्रति दिन 1 GB/s और 86.4 TB तार्किक डेटा है, जिसमें तीन रेप्लिका राइट्स के लिए 259.2 TB की निचली सीमा है। 15 मिनट के लिए तीन गुना पीक 1.8 TB अतिरिक्त बैकलॉग बनाता है जब कंज्यूमर क्षमता स्थिर स्थिति में रहती है। यदि पीक के बाद की शुद्ध कैच-अप दर 0.5 GB/s है, तो इसे ड्रेन करने में सिद्धांत रूप में लगभग एक घंटा लगता है। पार्टीशन गणना मैसेज-दर और बाइट-दर गणनाओं में से बड़े का उपयोग करती है, विफलता हेडरूम जोड़ती है, और वास्तविक हार्डवेयर पर कैलिब्रेट की जाती है।

256 KiB से ऊपर के पेलोड बॉडीज पहले ऑब्जेक्ट स्टोरेज में प्रवेश करते हैं। कतार एक अपरिवर्तनीय संदर्भ, साइज़ और चेकसम को बनाए रखती है। अपलोड-सत्र TTL अनाथों को हटा देता है, जबकि एक कमिटेड संदर्भ रिटेंशन, रिप्ले और डेड-लेटर विंडो के माध्यम से अपने ऑब्जेक्ट की सुरक्षा करता है। रीप्रयास मूल मैसेज ID को सुरक्षित रखते हैं। एक सख्त ऑर्डर्ड टॉपिक पॉइज़न मैसेज पर एक कुंजी या पार्टीशन को रोकता है क्योंकि इसे तुरंत डेड-लेटर करने से बाद के मैसेज गुजर सकते हैं।

अंत में, मैं प्रति किरायेदार इनग्रेस, एग्रेस, स्टोरेज, पार्टीशन्स और बड़े ऑब्जेक्ट्स को सीमित करूँगा; एक समर्पित पूल में एक हॉट किरायेदार को अलग करूँगा; और एक्नॉलेजमेंट लेटेंसी, अज्ञात पब्लिश, रेप्लिका लैग, डिस्क वॉटरमार्क, सबसे पुरानी कंज्यूमर आयु, हॉट कीज़ और डेड लेटर्स की निगरानी करूँगा। फॉल्ट परीक्षण खोए हुए एक्नॉलेजमेंट्स, कमिट से पहले और बाद में लीडर क्रैश, ज़ोन विफलता, बासी ऑफसेट कमिट्स, व्यावसायिक राइट्स के बाद कंज्यूमर क्रैश और ऑब्जेक्ट-स्टोरेज विफलता को कवर करते हैं। प्रत्येक परीक्षण विशिष्ट एक्नॉलेजमेंट सीमा की जांच करता है।"

सामान्य गलतियाँ

• गलती: केवल Producer, Kafka, और Consumer ड्रा करना → विफलता: घटक नाम एक्नॉलेजमेंट, ऑफसेट, ऑर्डर, या विफलता सीमाओं को परिभाषित नहीं करते हैं → सुधार: डिलीवरी कॉन्ट्रैक्ट और चार इनवेरिएंट्स बताएं, फिर प्रत्येक घटक को एक पर मैप करें।
• गलती: क्षैतिज रूप से स्केल करते समय वैश्विक क्रम का वादा करना → विफलता: वैश्विक क्रम को एक सीरियल निर्णय बिंदु की आवश्यकता होती है, जबकि पार्टीशन समानता उस क्रम को हटा देती है → सुधार: व्यावसायिक कुंजी और पार्टीशन के लिए ऑर्डर का दायरा तय करें और हॉट-की सीमा बताएं।
• गलती: लीडर के स्थानीय डिस्क राइट के बाद एक्नॉलेज करना → विफलता: लीडर के उपलब्धता क्षेत्र को खोने से एकमात्र ड्यूरेबल कॉपी हट सकती है → सुधार: क्रॉस-ज़ोन कमिट बहुमत के बाद एक्नॉलेज करें और केवल कमिटेड प्रीफ़िक्स वाले रेप्लिका का चुनाव करें।
• गलती: फेच करने पर तुरंत ऑफसेट कमिट करना → विफलता: उस कमिट के बाद एक क्रैश व्यावसायिक परिणाम को स्थायी रूप से छोड़ देता है → सुधार: पहले इडेम्पोटेंट व्यावसायिक परिणाम कमिट करें, फिर अगला ऑफसेट, और नियंत्रित रिप्ले स्वीकार करें।
• गलती: ब्रोकर एक्जेक्टली-वन्स की तुलना एक्जेक्टली-वन्स बाहरी प्रभावों से करना → विफलता: बाहरी सिस्टम ब्रोकर ट्रांजेक्शन में शामिल नहीं होता है, इसलिए एक्नॉलेजमेंट का नुकसान अभी भी एक डुप्लिकेट विंडो छोड़ता है → सुधार: व्यावसायिक इडेम्पोटेंसी कुंजी, अद्वितीय बाधा, संस्करण स्थिति, या समाधान का उपयोग करें।
• गलती: प्रत्येक विफल मैसेज को तुरंत डेड-लेटर करना → विफलता: एक ही कुंजी के लिए बाद के रिकॉर्ड इसे पार कर सकते हैं और स्थिति क्रम को तोड़ सकते हैं → सुधार: टॉपिक कॉन्ट्रैक्ट को एक रुकी हुई कुंजी, रुके हुए पार्टीशन, या संस्करण-आधारित अभिसरण को चुनने दें।
• गलती: 100 MB पेलोड को सीधे ब्रोकर लॉग में लिखना → विफलता: कुछ रिकॉर्ड्स रेप्लिकेशन, बफ़र्स और फेच बैचों पर एकाधिकार करते हैं → सुधार: बॉडी को ऑब्जेक्ट स्टोरेज में स्टोर करें और इसके संदर्भ, साइज़ और चेकसम को लॉग करें।
• गलती: केवल मैसेज काउंट द्वारा कोटा और क्षमता की योजना बनाना → विफलता: 1 KB रिकॉर्ड और 100 MB रिकॉर्ड में मौलिक रूप से भिन्न नेटवर्क, डिस्क और मेमोरी लागत होती है → सुधार: गणना, बाइट्स, इन-फ़्लाइट बैच और ऑब्जेक्ट समवर्तीता को मापें।
• गलती: प्रत्येक लैग को समाप्त करने के लिए कंज्यूमर्स जोड़ना → विफलता: एक ग्रुप सदस्य एक समय में एक पार्टीशन का मालिक होता है, और एक हॉट की सीरियल पार्टीशन पाथ द्वारा सीमित रहती है → सुधार: पार्टीशन्स जोड़ने, व्यावसायिक कुंजी को विभाजित करने, या थ्रॉटल करने से पहले पार्टीशन और कुंजी वितरण का निरीक्षण करें।
• गलती: केवल ब्रोकर अपटाइम की निगरानी करना → विफलता: एक लाइव क्लस्टर में अभी भी लैगिंग रेप्लिका, समाप्त डिस्क, बासी ऑफसेट और बढ़ते डेड लेटर्स हो सकते हैं → सुधार: खंडित लेटेंसी, कमिटेड प्रीफ़िक्स, सबसे पुराने-मैसेज की आयु, कैच-अप समय और एंड-टू-एंड कैनरी की निगरानी करें।

फॉलो-अप प्रश्न और प्रतिक्रियाएं

फॉलो-अप 1: पब्लिश p99 को 50 मिलीसेकंड से कम रखते हुए आप शून्य क्रॉस-रीजन डेटा हानि कैसे प्रदान करेंगे?

सिंक्रोनस क्रॉस-रीजन एक्नॉलेजमेंट पब्लिश पाथ में वाइड-एरिया राउंड-ट्रिप समय जोड़ता है। क्या 50 मिलीसेकंड संभव है यह क्षेत्र की दूरी और टेल नेटवर्क लेटेंसी पर निर्भर करता है। व्यवसाय को स्थानीय लेटेंसी के मुकाबले शून्य RPO को रैंक करना होगा। जब शून्य RPO जीतता है, तो एक राइट दूरस्थ कमिट बहुमत की प्रतीक्षा करता है और लेटेंसी SLO को रीसेट किया जाना चाहिए। जब लेटेंसी जीतती है, तो रेप्लिकेशन क्षेत्र के भीतर सिंक्रोनस होता है और क्षेत्रों में एसिंक्रोनस होता है, जिसमें अनरेप्लिकेटेड टेल के लिए एक स्पष्ट जोखिम होता है। एक्टिव-एक्टिव को प्रत्येक कुंजी के लिए एक मालिक या एक संघर्ष नियम की भी आवश्यकता होती है; प्रति टॉपिक या कुंजी सीमा पर एक एकल प्राथमिक क्षेत्र आमतौर पर ऑर्डर को अधिक स्पष्ट रूप से सुरक्षित रखता है।

फॉलो-अप 2: एक किरायेदार के पास प्रति सेकंड 200,000 मैसेजेस पर एक ही व्यावसायिक कुंजी है। 128 पार्टीशन्स क्यों मदद नहीं करते हैं?

ऑर्डर बनाए रखने के लिए एक ही कुंजी एक पार्टीशन पर रहनी चाहिए, इसलिए यह अभी भी लगभग 40,000 मैसेजेस प्रति सेकंड की बेंचमार्क एकल-पार्टीशन दर द्वारा सीमित है। विकल्प सीरियल पाथ को अनुकूलित करना, उस किरायेदार को थ्रॉटल करना, या स्वतंत्र ऑर्डर डोमेन को फिर से परिभाषित करना है, जैसे कि सब-एंटीटी कुंजियाँ जो एक दूसरे को प्रभावित नहीं करती हैं। यदि व्यवसाय को उस कुंजी के लिए कुल ऑर्डर की आवश्यकता होती है, तो सेवा को सीरियल क्षमता से ऊपर के वादे को अस्वीकार करना होगा। कुंजी को यादृच्छिक रूप से बिखेरना केवल एक ऑर्डरिंग विफलता के लिए क्षमता विफलता का आदान-प्रदान करता है।

फॉलो-अप 3: एक कंज्यूमर ने भुगतान चार्ज किया और फिर अपना ऑफसेट कमिट करने से पहले क्रैश हो गया। आप दूसरे चार्ज को कैसे रोकते हैं?

भुगतान इडेम्पोटेंसी कुंजी के रूप में message_id या व्यावसायिक ऑपरेशन ID का उपयोग करें। यदि भुगतान प्रदाता एक इडेम्पोटेंट API का समर्थन करता है, तो रिप्ले उसी कुंजी का उपयोग करता है और मूल परिणाम की क्वेरी करता है। यदि केवल स्थानीय डेटाबेस नियंत्रित है, तो एक ट्रांजेक्शन में व्यावसायिक स्थिति और एक प्रोसेस किए गए मैसेज का अद्वितीय रिकॉर्ड कमिट करें, फिर बाहरी चरण के लिए आउटबॉक्स का उपयोग करें। जब बाहरी सिस्टम में न तो इडेम्पोटेंसी होती है और न ही स्थिति लुकअप, तो एक UNKNOWN स्थिति रिकॉर्ड करें, समाधान करें, और मैन्युअल रूप से क्षतिपूर्ति करें। ऑफसेट को जल्दी कमिट करना केवल नुकसान को स्वीकार करके अनिश्चितता को छुपाता है।

फॉलो-अप 4: आप पॉइज़न मैसेज को सुरक्षित रूप से कैसे रीड्राइव करते हैं?

पहले कंज्यूमर या डेटा की मरम्मत करें, रीड्राइव के दायरे को फ्रीज करें, और मूल मैसेज ID, स्रोत ऑफसेट, पहली बार देखे जाने का समय, और प्रयास इतिहास को सुरक्षित रखें। शैडो कंजम्पशन के साथ नए संस्करण को सत्यापित करें, फिर सिंक इडेम्पोटेंसी को सक्रिय रखते हुए प्रति-किरायेदार और प्रति-पार्टीशन दर पर रिप्ले करें। एक सख्त ऑर्डर्ड टॉपिक कुंजी के लिए बाद के रिकॉर्ड्स को भी रोकता है और क्रम में विफल ऑफसेट से फिर से शुरू होता है। यदि कॉन्ट्रैक्ट पुन: ऑर्डर करने की अनुमति देता है, तो सिंक पुराने व्यावसायिक संस्करणों को अस्वीकार कर देता है। रीड्राइव को डिडुप्लिकेशन को बायपास करने के लिए एक नया ID नहीं बनाना चाहिए या अपने सामान्य ट्रैफ़िक पीक के दौरान मुख्य टॉपिक को ओवरफ्लो नहीं करना चाहिए।

फॉलो-अप 5: जब रिटेंशन 24 घंटे से बढ़कर 30 दिन हो जाता है तो पहले क्या बदलता है?

स्थिर स्थिति में, 30 दिन तार्किक रूप से लगभग 86.4 × 30 = 2.592 PB होता है। तीन पूर्ण स्थानीय रेप्लिका रखने की निचली सीमा 7.776 PB के करीब है, जिससे लागत और पुनर्प्राप्ति समय प्रमुख हो जाता है। ब्रोकर्स पर सक्रिय और हाल के सेगमेंट्स रखें, और बंद, सत्यापित सेगमेंट्स को ऑब्जेक्ट स्टोरेज में अपलोड करें। मेटाडेटा ऑब्जेक्ट स्थान और चेकसम रिकॉर्ड करता है; ऐतिहासिक फेच एक कैश या रीड प्रॉक्सी का उपयोग करते हैं। विलोपन, रिप्ले, कॉम्पेक्शन और ऑब्जेक्ट लाइफ़साइकिल को एक रिटेंशन स्टेट मशीन साझा करनी चाहिए ताकि रिमोट ऑब्जेक्ट के पठनीय होने से पहले कोई स्थानीय सेगमेंट कभी हटाया न जाए।