सिस्टम डिज़ाइन इंटरव्यू: एक विश्वसनीय वेबहुक डिलीवरी प्लेटफ़ॉर्म डिज़ाइन करें

समस्या और कार्यक्षेत्र (स्कोप)

एक SaaS प्लेटफ़ॉर्म invoice.paid, order.shipped, और user.disabled जैसे इवेंट्स उत्सर्जित करता है। ग्राहक HTTPS एंडपॉइंट्स पंजीकृत करते हैं और प्रत्येक एंडपॉइंट को चयनित इवेंट प्रकारों के लिए सब्सक्राइब करते हैं। कमिट किए गए व्यावसायिक इवेंट से लेकर ग्राहक के HTTP रिस्पॉन्स तक आउटबाउंड प्लेटफ़ॉर्म को डिज़ाइन करें। एंडपॉइंट प्रशासन, डिलीवरी इतिहास, सीक्रेट रोटेशन और मैन्युअल रिप्ले स्कोप में हैं। अनुरोध को स्वीकार करने के बाद ग्राहक की आंतरिक प्रोसेसिंग प्लेटफ़ॉर्म के नियंत्रण से बाहर है।

इन इंटरव्यू मान्यताओं का उपयोग करें:

• उत्पाद प्रतिदिन 5 करोड़ (50 मिलियन) व्यावसायिक इवेंट्स बनाता है। प्रत्येक इवेंट औसतन चार एंडपॉइंट्स से मेल खाता है, जिससे प्रतिदिन 20 करोड़ (200 मिलियन) लॉजिकल डिलीवरी बनती हैं।
• औसत लोड लगभग 579 इवेंट्स और 2,315 नई डिलीवरी प्रति सेकंड है। दस गुना पीक लगभग 5,787 इवेंट्स और 23,148 नई डिलीवरी प्रति सेकंड है।
• यदि पुनः प्रयास (रिट्राइज़) 10% अतिरिक्त प्रयास जोड़ते हैं, तो पीक डिस्पैच पाथ को प्रति सेकंड लगभग 25,463 प्रयासों को बनाए रखना चाहिए।
• सामान्य पीक के तहत, 99% योग्य नई डिलीवरी को अपना पहला प्रयास 10 सेकंड के भीतर शुरू करना चाहिए। पुनः प्रयासों की 24 घंटे की समय सीमा (डेडलाइन) होती है, और डिलीवरी इतिहास 30 दिनों तक क्वेरी करने योग्य रहता है।
• 1.5 KB इम्यूटेबल इवेंट पेलोड, 300 बाइट्स डिलीवरी मेटाडेटा, 250 बाइट्स प्रति प्रयास, और 1.1 प्रयास प्रति डिलीवरी के साथ, लॉजिकल स्टोरेज लगभग 190 GB प्रति दिन या 30 दिनों के लिए 5.7 TB है। इसमें इंडेक्स, रेप्लिकास, कम्प्रेशन और ऑब्जेक्ट-स्टोर ओवरहेड शामिल नहीं हैं।

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

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

पहला संकेत यह है कि उम्मीदवार पहचानकर्ताओं (आइडेंटिफायर्स) और गारंटी को कितनी सटीकता से परिभाषित करता है। एक event_id एक कमिट किए गए व्यावसायिक तथ्य का प्रतिनिधित्व करता है। एक delivery_id उस इवेंट का प्रतिनिधित्व करता है जो एक एंडपॉइंट पर जा रहा है और स्वचालित पुनः प्रयासों तथा मैन्युअल पुनर्वितरण के दौरान स्थिर रहता है। (event_id, endpoint_id) पर एक यूनिक कंस्ट्रेंट फैन-आउट रिप्ले को दूसरी लॉजिकल डिलीवरी बनाने से रोकता है। यह उसी HTTP अनुरोध को ग्राहक तक दो बार पहुँचने से नहीं रोकता है जब कोई वर्कर रिस्पॉन्स खो देता है।

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

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

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

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• सफलता क्या है? यह डिज़ाइन किसी भी 2xx रिस्पॉन्स को एंडपॉइंट स्वीकृति (एक्नॉलेजमेंट) मानता है। 3xx, टाइमआउट, कनेक्शन त्रुटि, 408, 429, या 5xx सफलता नहीं है। पावती यह साबित नहीं करती कि ग्राहक की बाद की व्यावसायिक प्रोसेसिंग सफल रही।
• किन इवेंट्स और पेलोड संस्करण का वादा किया गया है? प्रत्येक इवेंट प्रकार को एक प्रलेखित स्कीमा और वर्ज़निंग नीति की आवश्यकता होती है। पुनः प्रयास समान अपरिवर्तनीय (इम्यूटेबल) पेलोड बाइट्स भेजते हैं; उन्हें वर्तमान डेटाबेस स्थिति से पुराने इवेंट्स का पुनर्निर्माण नहीं करना चाहिए।
• किस क्रम की आवश्यकता है? डिफ़ॉल्ट डिलीवरी अव्यवस्थित (अनऑर्डर्ड) है। यदि किसी ग्राहक को एक एग्रीगेट के लिए क्रम की आवश्यकता है, तो object_id और मोनोटोनिक रूप से बढ़ते object_version को शामिल करें, या एक ऑप्ट-इन ऑर्डरिंग कुंजी प्रदान करें जो हेड-ऑफ़-लाइन ब्लॉकिंग को स्वीकार करती है। वैश्विक क्रम न तो आवश्यक है और न ही वहन करने योग्य।
• प्लेटफ़ॉर्म कब तक पुनः प्रयास और रिप्ले कर सकता है? यहाँ, स्वचालित पुनः प्रयास 24 घंटे के बाद रुक जाते हैं और लॉग्स 30 दिनों तक रहते हैं। स्वचालित विंडो के बाद का रिप्ले मूल इवेंट और डिलीवरी पहचान का उपयोग करता है लेकिन एक नया प्रयास रिकॉर्ड बनाता है।
• क्या एंडपॉइंट्स कहीं भी इंगित कर सकते हैं? उत्पाद केवल सार्वजनिक HTTPS एंडपॉइंट्स स्वीकार करता है। IPv4 और IPv6 के लिए निजी, लूपबैक, लिंक-लोकल, मल्टीकास्ट, आरक्षित और क्लाउड-मेटाडेटा गंतव्यों को अस्वीकार कर दिया जाता है।
• प्लेटफ़ॉर्म से क्या डेटा बाहर जा सकता है? सब्सक्रिप्शन प्राधिकरण और पेलोड न्यूनीकरण फैन-आउट का हिस्सा हैं। संवेदनशील फ़ील्ड्स को छोड़ दिया जाता है या किसी संसाधन संदर्भ द्वारा दर्शाया जाता है जब एकीकरण उन्हें एक प्रमाणित API के माध्यम से प्राप्त कर सकता है।

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

“मैं प्रत्येक व्यावसायिक इवेंट को एक आउटबॉक्स के माध्यम से कमिट करूँगा, इसे एक टिकाऊ इवेंट लॉग में प्रकाशित करूँगा, और एक फैन-आउट सेवा से सक्रिय सब्सक्रिप्शन को हल करवाऊँगा। यह कतार में कार्य डालने से पहले प्रति (event_id, endpoint_id) एक डिलीवरी पंक्ति बनाता है। वर्कर लीज़ के साथ प्रयासों का दावा करते हैं, प्रति-एंडपॉइंट और प्रति-टेनेंट सीमाएं लागू करते हैं, स्थिर डिलीवरी आईडी और वर्तमान प्रयास टाइमस्टैम्प के साथ अपरिवर्तनीय बाइट्स पर हस्ताक्षर करते हैं, और HTTPS पर भेजते हैं। एक 2xx डिलीवरी को पूरा करता है; पुनः प्रयास योग्य विफलताएं 24 घंटे की समय सीमा तक पूर्ण जिटर के साथ एक्सपोनेंशियल बैकऑफ़ का उपयोग करती हैं, जबकि स्थायी विफलताएं रुक जाती हैं। चूँकि भेजने के बाद का टाइमआउट अस्पष्ट होता है, अनुबंध एट-लीस्ट-वन्स है और ग्राहक डिलीवरी आईडी द्वारा डिडुप्लिकेट करते हैं। मैं हस्ताक्षरित सीक्रेट रोटेशन, SSRF-सुरक्षित URL सत्यापन, डिलीवरी लॉग्स और रिप्ले, एंडपॉइंट सर्किट ब्रेकर्स, और मिलान (रीकंसीलिएशन) जोड़ूँगा जो आउटबॉक्स, फैन-आउट, या कतार अंतराल का पता लगाता है।”

चरण-दर-चरण विस्तृत विश्लेषण (डीप डाइव)

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

कंट्रोल-प्लेन APIs छोटे और स्पष्ट हो सकते हैं:

POST /v1/webhook-endpoints
PATCH /v1/webhook-endpoints/{endpoint_id}
POST /v1/webhook-endpoints/{endpoint_id}/rotate-secret
GET  /v1/webhook-deliveries?endpoint_id=&status=&cursor=
POST /v1/webhook-deliveries/{delivery_id}/replay

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

चार टिकाऊ रिकॉर्ड्स का उपयोग करें:

Endpoint(endpoint_id, tenant_id, url, status, event_types,
         current_secret_version, previous_secret_version, config_version)

Event(event_id, tenant_id, type, schema_version, object_id,
      object_version, occurred_at, payload_ref, payload_hash)

Delivery(delivery_id, event_id, endpoint_id, endpoint_config_version,
         status, attempt_count, next_attempt_at, expires_at, lease_version)

Attempt(attempt_id, delivery_id, attempt_number, started_at, finished_at,
        http_status, latency_ms, error_class, response_digest)

फैन-आउट सेवा एक इवेंट को पढ़ती है, उस टेनेंट और इवेंट प्रकार के लिए अधिकृत सक्रिय सब्सक्रिप्शन लोड करती है, फिर सीमित बैचों में डिलीवरी पंक्तियाँ डालती है। डेटाबेस (event_id, endpoint_id) पर विशिष्टता लागू करता है। पंक्तियाँ मौजूद होने के बाद ही यह delivery_id मानों को कतारबद्ध करता है। यदि कतारबद्ध करना विफल हो जाता है, तो एक स्वीपर सक्रिय कतार कार्य के बिना देय PENDING पंक्तियों को ढूंढता है। यदि फैन-आउट प्रक्रिया बीच में क्रैश हो जाती है, तो रिप्ले लुकअप को दोहराता है और विशिष्टता प्रतिबंध केवल लापता पंक्तियों को भरता है। एक संग्रहीत सब्सक्रिप्शन स्नैपशॉट या एंडपॉइंट कॉन्फ़िगरेशन संस्करण बाद के ऑडिट को व्याख्या योग्य बनाता है।

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

एक वर्कर लीज़ और बढ़ते हुए lease_version के साथ परमाणु रूप से (एटोमिकली) एक डिलीवरी का दावा करता है। यह संग्रहीत पेलोड बाइट्स को पढ़ता है, प्रयास टाइमस्टैम्प बनाता है, और HMAC-SHA256 के साथ delivery_id.timestamp.payload_bytes जैसी एक कैनोनिकल स्ट्रिंग पर हस्ताक्षर करता है। यह सटीक हस्ताक्षरित बाइट्स और हेडर भेजता है जिसमें इवेंट का प्रकार, डिलीवरी आईडी, इवेंट होने का समय, प्रयास का समय, स्कीमा संस्करण और हस्ताक्षर संस्करण शामिल होते हैं। उपभोक्ता कॉन्स्टेंट-टाइम तुलना का उपयोग करके कच्चे बाइट्स को सत्यापित करता है, टाइमस्टैम्प सहनशीलता की जांच करता है, और स्थिर डिलीवरी आईडी को डिडुप्लिकेट करता है। प्रत्येक पुनः प्रयास को डिलीवरी आईडी और इवेंट बाइट्स को बनाए रखते हुए एक नया प्रयास टाइमस्टैम्प और हस्ताक्षर मिलता है।

रिस्पॉन्स नीति नियतात्मक (डिटरमिनिस्टिक) होनी चाहिए। कोई भी 2xx डिलीवरी को SUCCEEDED के रूप में चिह्नित करता है। 3xx का स्वचालित रूप से अनुसरण न करें। 408, 429, 5xx, कनेक्शन रीसेट और टाइमआउट को पुनः प्रयास योग्य मानें, और 429 या 503 पर एक सीमित Retry-After का सम्मान करें; अधिकांश अन्य 4xx रिस्पॉन्स उस कॉन्फ़िगरेशन के लिए स्थायी होते हैं। TLS और DNS विफलताएं पुनः प्रयास योग्य के रूप में शुरू हो सकती हैं लेकिन एंडपॉइंट सर्किट को तुरंत खोल देती हैं। पूर्ण जिटर, अधिकतम विलंब, अधिकतम प्रयास गणना और 24 घंटे की पूर्ण समय सीमा के साथ एक्सपोनेंशियल बैकऑफ़ का उपयोग करें। अनुरोध के वर्कर से निकलने के बाद टाइमआउट एक अज्ञात परिणाम है: पुनः प्रयास करने से ग्राहक की प्रोसेसिंग डुप्लिकेट हो सकती है, इसलिए प्लेटफ़ॉर्म को कभी भी सटीक रूप से एक बार (एक्जेक्टली वन्स) का विज्ञापन नहीं करना चाहिए।

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

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

क्षमता केवल इवेंट गणना के बजाय फैन-आउट का अनुसरण करती है। 5 करोड़ इवेंट्स गुणा चार सब्सक्रिप्शन प्रतिदिन 20 करोड़ डिलीवरी उत्पन्न करते हैं। प्रत्येक 1.1 प्रयासों पर, प्रयास इतिहास प्रतिदिन 22 करोड़ पंक्तियाँ हैं। माने गए कच्चे आकार 50M × 1.5 KB = 75 GB, 200M × 300 B = 60 GB, और 220M × 250 B = 55 GB देते हैं, जो कुल मिलाकर लगभग 190 GB प्रति दिन होते हैं। वर्तमान देय-स्थिति इंडेक्स को छोटा रखें, समय और टेनेंट हैश द्वारा इतिहास को विभाजित करें, और सस्ते स्टोरेज में अपरिवर्तनीय पेलोड और पुराने प्रयासों को संग्रहीत (आर्काइव) करें। इवेंट-टू-फैन-आउट अंतराल, सबसे पुरानी नई और पुनः प्रयास आयु, प्रथम-प्रयास विलंबता, एंडपॉइंट और स्थिति वर्ग द्वारा सफलता, पुनः प्रयास प्रवर्धन (एम्प्लीफिकेशन), सर्किट स्थिति, टेनेंट थ्रॉटलिंग, और रिप्ले परिणामों को मापें।

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

मजबूत नमूना उत्तर (स्ट्रॉन्ग सैंपल आंसर)

“मैं प्रत्येक कमिट किए गए व्यावसायिक तथ्य को एक अपरिवर्तनीय event_id, और प्रत्येक इवेंट-एंडपॉइंट जोड़ी को एक स्थिर delivery_id दूँगा। उत्पादक अपने व्यावसायिक लेनदेन में इवेंट को एक आउटबॉक्स में लिखता है। एक रिले एक टिकाऊ लॉग में प्रकाशित करता है, और फैन-आउट उन्हें कतारबद्ध करने से पहले एक अद्वितीय (event_id, endpoint_id) बाधा के तहत डिलीवरी को भौतिक रूप देता है। यह रिप्ले को दूसरी लॉजिकल डिलीवरी बनाए बिना लापता कार्य की मरम्मत करने की अनुमति देता है।

बताए गए पीक पर, फैन-आउट प्रति सेकंड लगभग 23,148 नई डिलीवरी बनाता है और डिस्पैच पाथ पुनः प्रयासों सहित प्रति सेकंड लगभग 25,463 प्रयासों की योजना बनाता है। एक शेड्यूलर नए और पुनः प्रयास कार्य को अलग करता है, भारित टेनेंट निष्पक्षता, प्रति-एंडपॉइंट समवर्तीता और टोकन बकेट लागू करता है, फिर वर्करों को वर्ज़न वाली लीज़ के साथ प्रयासों का दावा करने देता है। इसलिए एक धीमा ग्राहक केवल अपने भत्ते का उपभोग करता है। बार-बार की विफलताएं एक एंडपॉइंट सर्किट खोलती हैं जबकि प्रोब और 24 घंटे की पुनः प्रयास समय सीमा दृश्यमान रहती है।

प्रत्येक प्रयास HMAC-SHA256 के साथ delivery_id, प्रयास टाइमस्टैम्प, और सटीक इम्यूटेबल पेलोड बाइट्स पर हस्ताक्षर करता है। ग्राहक कॉन्स्टेंट-टाइम तुलना के साथ हस्ताक्षर की जांच करता है, पुराने टाइमस्टैम्प को अस्वीकार करता है, और स्थिर डिलीवरी आईडी को डिडुप्लिकेट करता है। एक 2xx सफल होता है। 408, 429, 5xx, नेटवर्क त्रुटियां, और टाइमआउट एक्सपोनेंशियल बैकऑफ़ और पूर्ण जिटर के साथ पुनः प्रयास करते हैं; अधिकांश अन्य 4xx रिस्पॉन्स रुक जाते हैं। ग्राहक द्वारा अनुरोध को प्रोसेस करने के बाद लेकिन सफलता रिकॉर्ड करने से पहले एक वर्कर क्रैश हो सकता है, इसलिए मैं एट-लीस्ट-वन्स का वादा करता हूँ और दस्तावेजित करता हूँ कि उपभोक्ताओं को इडेम्पोटेंट होना चाहिए।

कंट्रोल प्लेन एंडपॉइंट और सब्सक्रिप्शन प्रबंधन, सीमित-ओवरलैप सीक्रेट रोटेशन, डिलीवरी लॉग्स और रिप्ले प्रदान करता है। एंडपॉइंट URLs एक पृथक इग्रेस नेटवर्क के अंदर HTTPS, IP-रेंज, DNS-रीबाइंडिंग, रीडायरेक्ट, टाइमआउट और रिस्पॉन्स-आकार नियंत्रण पास करते हैं। मैं प्रत्येक टिकाऊ सीमा का मिलान करके और डुप्लिकेट प्रकाशन, आंशिक फैन-आउट, खोई हुई स्वीकृतियां, बड़े पैमाने पर 429 रिस्पॉन्स, और हैंग होने वाले एंडपॉइंट्स से भरे एक टेनेंट को इंजेक्ट करके डिज़ाइन को साबित करूँगा। पास मानदंड प्रथम-प्रयास SLO, कोई अस्पष्ट डिलीवरी अंतराल नहीं, सीमित पुनः प्रयास प्रवर्धन, और स्वस्थ टेनेंट्स के लिए निष्पक्ष पुनर्प्राप्ति हैं।”

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

• व्यावसायिक डेटा कमिट करने के बाद प्रकाशित करना → दो कार्यों के बीच क्रैश होने से वेबहुक इवेंट खो जाता है → एक ट्रांजेक्शनल आउटबॉक्स लिखें या इसके समकक्ष टिकाऊ चेंज स्ट्रीम का उपभोग करें।
• प्रत्येक पुनः प्रयास के लिए एक नई डिलीवरी आईडी बनाना → प्राप्तकर्ता एक लॉजिकल डिलीवरी को डिडुप्लिकेट नहीं कर सकता है → delivery_id को स्थिर रखें और अलग प्रयास रिकॉर्ड बनाएं।
• सटीक रूप से एक बार (एक्जेक्टली-वन्स) HTTP डिलीवरी का वादा करना → रिमोट प्रोसेसिंग के बाद खोया हुआ रिस्पॉन्स प्रेषक को परिणाम जानने में असमर्थ छोड़ देता है → एट-लीस्ट-वन्स डिलीवरी की पेशकश करें और इडेम्पोटेंट उपभोक्ता हैंडलिंग की आवश्यकता रखें।
• पुनः प्रयास पर पेलोड का पुनर्निर्माण करना → वर्तमान डेटाबेस स्थिति ऐतिहासिक घटना को बदल देती है और पुराने हस्ताक्षरों को अमान्य कर देती है → कैनोनिकल अपरिवर्तनीय इवेंट बाइट्स और उनके स्कीमा संस्करण को संग्रहीत करें।
• प्रत्येक एंडपॉइंट के लिए एक FIFO का उपयोग करना → धीमे गंतव्य कनेक्शन पर कब्जा कर लेते हैं और स्वस्थ ग्राहकों में देरी करते हैं → प्रति-एंडपॉइंट कार्य को सीमित करें और टेनेंट निष्पक्षता के साथ शेड्यूल करें।
• प्रत्येक गैर-2xx का तुरंत पुनः प्रयास करना → स्थायी विफलताएं क्षमता बर्बाद करती हैं और सिंक्रनाइज़ किए गए पुनः प्रयास घटनाओं को बढ़ाते हैं → त्रुटियों को वर्गीकृत करें और पूर्ण जिटर और एक समय सीमा के साथ एक्सपोनेंशियल बैकऑफ़ का उपयोग करें।
• ग्राहक URLs से रीडायरेक्ट्स का पालन करना → एक सार्वजनिक URL वर्करों को आंतरिक सेवाओं पर रीडायरेक्ट कर सकता है → रीडायरेक्ट्स को अक्षम करें या पृथक इग्रेस में प्रत्येक हॉप को पूरी तरह से पुनः मान्य करें।
• पार्स किए गए JSON पर हस्ताक्षर करना → पुन: सीरियलाइज़ेशन बाइट्स को बदलता है और वैध हस्ताक्षरों को विफल करने का कारण बनता है → सटीक कच्चे मुख्य भाग (रॉ बॉडी) के साथ प्रमाणित आईडी और टाइमस्टैम्प मेटाडेटा पर हस्ताक्षर करें और सत्यापित करें।
• डैशबोर्ड रिप्ले को एक नए इवेंट के रूप में मानना → डाउनस्ट्रीम ग्राहक एक नई पहचान के तहत व्यावसायिक तथ्य को दो बार लागू कर सकते हैं → मौजूदा डिलीवरी को रिप्ले करें और एक नया प्रयास रिकॉर्ड करें।

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: प्लेटफ़ॉर्म सटीक रूप से एक बार डिलीवरी की गारंटी क्यों नहीं दे सकता?

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

फॉलो-अप 2: आप एक टूटे हुए एंडपॉइंट को बाकी सभी में देरी करने से कैसे रोकते हैं?

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

फॉलो-अप 3: आप क्या ऑर्डरिंग गारंटी देंगे?

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

फॉलो-अप 4: साइनिंग-सीक्रेट रोटेशन के दौरान क्या होता है?

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

फॉलो-अप 5: फैन-आउट केवल आंशिक रूप से पूरा होने के बाद आप कैसे पुनर्प्राप्त करते हैं?

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

फॉलो-अप 6: क्या मैन्युअल रिप्ले को 24 घंटे की समय सीमा रीसेट करनी चाहिए?

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