किराया सॉफ़्टवेयर के लिए वेबहुक: रीयल-टाइम इंटीग्रेशन सिस्टम को कैसे सिंक में रखते हैं

पोलिंग: बार-बार वही सवाल पूछना

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

ज़्यादातर समय, कुछ भी नहीं बदला होता। आप रिक्वेस्ट भेजते हैं, बिल्कुल पिछली बार जैसा ही रिस्पॉन्स वापस मिलता है, और आप उसे फेंक देते हैं। इसे हर पांच मिनट में दोहराएं, दिन में 288 बार, हर उस अकाउंट के लिए जिसे आप सिंक कर रहे हैं, और आप लगभग हर बार यह जानने के लिए API कॉल्स, डेटाबेस क्वेरीज़ और कंप्यूट साइकिल खर्च कर रहे हैं कि कुछ नहीं हुआ।

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

एक वेबहुक इस व्यवस्था को पलट देता है। आपके सिस्टम के बार-बार यह पूछने के बजाय कि क्या कुछ बदला है, किराया सिस्टम आपको उसी क्षण बताता है जब वास्तव में कुछ होता है। आप पूछने की लागत चुकाना बंद कर देते हैं और केवल उन पलों के लिए भुगतान करना शुरू करते हैं जो वाकई मायने रखते हैं।

वेबहुक असल में क्या होता है

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

यही एक सामान्य API कॉल से मूल अंतर है। एक सामान्य API रिक्वेस्ट pull-आधारित होती है: आप तय करते हैं कि कब पूछना है, और सिस्टम केवल तभी जवाब देता है जब उससे पूछा जाए। एक वेबहुक push-आधारित होता है: सिस्टम खुद तय करता है कि आपको कब बताना है, अपनी खुद की घटनाओं के आधार पर, न कि आपके शेड्यूल के आधार पर। रिक्वेस्ट की उत्पत्ति किसी घटना से होती है, न कि किसी क्लाइंट से जो उसी वक़्त कुछ जानना चाहता है।

व्यवहार में, इससे आपके इंटीग्रेशन कोड का पूरा स्वरूप बदल जाता है। डेटा लाने और तुलना करने वाले लूप के बजाय, आप एक छोटा हैंडलर लिखते हैं जो रिक्वेस्ट प्राप्त करता है, यह सत्यापित करता है कि यह वाकई अपेक्षित सिस्टम से आई है, और जो घटना बताई गई है उसके अनुसार प्रतिक्रिया देता है। उदाहरण के लिए, Renttix अपने डेवलपर API के हिस्से के रूप में वेबहुक एंडपॉइंट्स उपलब्ध कराता है, ताकि कोई बिज़नेस एक URL रजिस्टर कर सके और बार-बार पूछने के बजाय सूचित किया जा सके।

किराया कारोबार में पोलिंग स्केल क्यों नहीं करती

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

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

वेबहुक इस पूरे समझौते को टाल देते हैं। आपको मिलने वाली नोटिफिकेशन्स की मात्रा वास्तव में हुई चीज़ों की संख्या के अनुपात में होती है, न कि इस बात पर निर्भर कि आप कितनी बार पूछने के लिए बेचैन महसूस करते हैं। एक शांत हफ्ता लगभग कोई वेबहुक ट्रैफिक पैदा नहीं करता; एक व्यस्त हफ्ता ठीक उतनी ही नोटिफिकेशन्स पैदा करता है जितनी घटनाएं हुई हों, उससे ज़्यादा नहीं।

रीयल-टाइम इंटीग्रेशन असल में क्या संभव बनाते हैं

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

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

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

अंधेरे में डीबग करना बनाम डिलीवरी लॉग होना

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

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

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

स्कोप्ड, रिवोकेबल API कीज़: सुरक्षित इंटीग्रेशन का दूसरा आधा हिस्सा

वेबहुक किसी इंटीग्रेशन के "जब कुछ हो तो मुझे बताओ" वाले हिस्से को संभालते हैं, लेकिन ज़्यादातर वास्तविक इंटीग्रेशन्स को सीधे API को भी कॉल करने की ज़रूरत होती है, अतिरिक्त विवरण लाने, कुछ खोजने, या डेटा वापस लिखने के लिए। इसके लिए एक API की चाहिए होती है, और API कीज़ को उतनी ही सावधानी की ज़रूरत होती है जितनी उनके चारों ओर वेबहुक डिज़ाइन को।

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

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

अपने किराया डेटा पर निर्माण करना, न कि उसे एक्सपोर्ट करना

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

एक डॉक्युमेंटेड REST API इस रिश्ते को बदल देता है। Renttix /api/v1 के तहत एक डॉक्युमेंटेड REST API उपलब्ध कराता है, जिसका मतलब है कि इंटीग्रेशन एक स्थिर, वर्णित इंटरफ़ेस पर बनाया जाता है, न कि किसी एक-बार के एक्सपोर्ट के जो भी आकार में हो उसके ऊपर। रीयल-टाइम नोटिफिकेशन के लिए वेबहुक के साथ, और ट्रैफिक की दोनों दिशाओं में दृश्यता के लिए डिलीवरी लॉग्स तथा रिक्वेस्ट लॉगिंग के साथ मिलकर, ऐसे टुकड़े मौजूद हैं जिनसे कुछ ऐसा बनाया जा सकता है जो आवधिक डेटा डंप की तुलना में सिस्टम्स के बीच लाइव कनेक्शन के ज़्यादा करीब हो।

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

शुरुआत कैसे करें

व्यावहारिक शुरुआती बिंदु छोटा है: वह एक जानकारी चुनें जिसे किसी डाउनस्ट्रीम सिस्टम को वाकई रीयल टाइम में जानना ज़रूरी है, उसके लिए एक वेबहुक एंडपॉइंट रजिस्टर करें, और एक ऐसी API की जनरेट करें जो केवल उतने तक स्कोप्ड हो जितना वह इंटीग्रेशन छूती है। टेस्ट करते समय डिलीवरी लॉग्स पर नज़र रखें, ताकि आप देख सकें कि वास्तव में क्या भेजा जा रहा है, अनुमान लगाने के बजाय।

वहां से, पैटर्न स्वाभाविक रूप से आगे बढ़ता है, और घटनाएं, और इंटीग्रेशन्स, हर एक की अपनी स्कोप्ड की के साथ, बिना कभी उस लूप पर वापस लौटे जो हर कुछ मिनट में वही सवाल पूछता रहता है। अगर आप यह सोच रहे हैं कि वेबहुक और API आपके सेटअप में कैसे फ़िट होंगे, तो आप क्या जोड़ना चाहते हैं इस बारे में टीम से बात करें।