फ़्लीट इंजन और फ़्लीट इवेंट रेफ़रंस सलूशन की मदद से, करीब-करीब रीयल-टाइम इवेंट जनरेट करें

ग्राउंड पर चल रहे फ़्लीट से मिलने वाले करीब-करीब रीयल टाइम सिग्नल, कारोबारों के लिए कई तरह से फ़ायदेमंद होते हैं. उदाहरण के लिए, कारोबार इनका इस्तेमाल इन कामों के लिए कर सकते हैं:

  • अपने फ़्लीट की परफ़ॉर्मेंस को मॉनिटर करना और संभावित समस्याओं की पहचान करना
  • ईटीए और ट्रैकिंग की सटीक जानकारी देकर, ग्राहक सेवा को बेहतर बनाना
  • खर्चों को कम करने के लिए, गड़बड़ियों की पहचान करना और उन्हें ठीक करना
  • ड्राइवर के व्यवहार पर नज़र रखकर और संभावित खतरों की पहचान करके सुरक्षा बढ़ाएँ
  • बेहतर परफ़ॉर्मेंस के लिए, ड्राइवर के रास्ते और शेड्यूल ऑप्टिमाइज़ करना
  • वाहन की जगह की जानकारी और सेवा के घंटे ट्रैक करके, कानूनों का पालन करें

इस दस्तावेज़ में बताया गया है कि डेवलपर, Google Maps Platform के "मोबिलिटी सेवाओं" के सिग्नल को, कार्रवाई वाले कस्टम इवेंट में कैसे बदल सकते हैं. इन सेवाओं में, "लास्ट माइल फ़्लीट सलूशन" (LMFS) या "ऑन-डिमांड राइड और डिलीवरी सलूशन" (ODRD) शामिल हैं. GitHub पर उपलब्ध फ़्लीट इवेंट के रेफ़रंस सलूशन के मुख्य कॉन्सेप्ट और डिज़ाइन से जुड़े फ़ैसले भी शामिल किए गए हैं.

यह दस्तावेज़ इनके लिए काम का है:

  • ऐसे आर्किटेक्ट जिन्हें Google Maps Platform की "मोबिलिटी सेवाओं" और इसके मुख्य कॉम्पोनेंट "Fleet Engine" में से एक के बारे में जानकारी है. हमारा सुझाव है कि नई "मोबिलिटी सेवाओं" के लिए, लास्ट माइल फ़्लीट सलूशन और/या मांग पर राइड और डिलीवरी की सुविधा के बारे में जानें. हालांकि, यह सुविधा आपकी ज़रूरतों के हिसाब से उपलब्ध होगी.
  • ऐसे आर्किटेक्ट जो Google Cloud के बारे में जानते हों. Google Cloud का इस्तेमाल करने वाले नए लोगों के लिए, Google Cloud पर स्ट्रीमिंग डेटा पाइपलाइन बनाना लेख को पहले पढ़ने का सुझाव दिया जाता है.
  • अगर आपको दूसरे एनवायरमेंट या सॉफ़्टवेयर स्टैक को टारगेट करना है, तो Fleet Engine के इंटिग्रेशन पॉइंट और अहम बातों को समझने पर फ़ोकस करें. ये बातें अब भी लागू होनी चाहिए.
  • ऐसे लोग जिन्हें यह जानना है कि फ़्लीट से इवेंट कैसे जनरेट और इस्तेमाल किए जा सकते हैं.

इस दस्तावेज़ के आखिर तक, आपको स्ट्रीमिंग सिस्टम के अहम एलिमेंट और ज़रूरी बातों की बुनियादी जानकारी हो जाएगी. साथ ही, आपको फ़्लीट इवेंट रेफ़रंस सलूशन बनाने के साथ-साथ Google Maps Platform और Google Cloud से भी ब्लॉक बनाने की जानकारी मिल जाएगी.

फ़्लीट इवेंट रेफ़रंस समाधान की खास जानकारी

Fleet इवेंट का रेफ़रंस सलूशन, एक ओपन सोर्स सलूशन है. इसकी मदद से, Mobility के ग्राहक और पार्टनर, Fleet Engine और Google Cloud के कॉम्पोनेंट के साथ-साथ मुख्य इवेंट जनरेट कर सकते हैं. फ़िलहाल, रेफ़रंस समाधान, लास्ट माइल फ़्लीट समाधान का इस्तेमाल करने वाले ग्राहकों के लिए उपलब्ध है. साथ ही, इसमें ऑन-डिमांड राइड और डिलीवरी की सुविधा भी उपलब्ध है.

टास्क या यात्राओं से जुड़े खास डेटा में हुए बदलावों के आधार पर, समाधान अपने-आप इवेंट जनरेट करता है. इन इवेंट का इस्तेमाल, हिस्सेदारों को सूचनाएं भेजने या अपने फ़्लीट के लिए अन्य कार्रवाइयां ट्रिगर करने के लिए किया जा सकता है. जैसे:

  • टास्क पूरा होने का अनुमानित समय बदलना
  • टास्क के पूरा होने के अनुमानित समय में बदलाव
  • टास्क पूरा होने में बचा समय
  • टास्क पूरा होने में बाकी समय
  • TaskOutcome के स्टेटस में बदलाव

रेफ़रंस सलूशन के हर कॉम्पोनेंट को अपने कारोबार की ज़रूरतों के हिसाब से बनाया जा सकता है.

लॉजिकल बिल्डिंग ब्लॉक

डायग्राम : इस डायग्राम में, फ़्लीट इवेंट के रेफ़रंस समाधान को बनाने वाले हाई लेवल बिल्डिंग ब्लॉक दिखाए गए हैं

फ़्लीट इवेंट की खास जानकारी और लॉजिकल बिल्डिंग ब्लॉक

रेफ़रंस सलूशन में ये कॉम्पोनेंट शामिल होते हैं:

  • इवेंट का सोर्स: इससे पता चलता है कि ओरिजनल इवेंट स्ट्रीम कहां से आती है. "लास्ट मिले फ़्लीट सलूशन" या "ऑन-डिमांड राइड और डिलीवरी सलूशन", दोनों में Cloud Logging के साथ इंटिग्रेशन है. इससे, Fleet Engine आरपीसी कॉल लॉग को डेवलपर के लिए उपलब्ध इवेंट स्ट्रीम में बदलने में मदद मिलती है. यह डेटा का मुख्य सोर्स है.
  • प्रोसेसिंग: इस ब्लॉक में, रॉ आरपीसी कॉल लॉग को स्टेटस में बदलाव करने वाले इवेंट में बदला जाता है. यह ब्लॉक, लॉग इवेंट की स्ट्रीम पर कैलकुलेट करता है. इस तरह के बदलाव का पता लगाने के लिए, इस कॉम्पोनेंट को स्टेटस स्टोर की ज़रूरत होती है, ताकि आने वाले नए इवेंट की तुलना पिछले इवेंट से की जा सके और बदलाव का पता लगाया जा सके. ऐसा हो सकता है कि इवेंट में, आपके काम की सारी जानकारी शामिल न हो. ऐसे मामलों में, यह ब्लॉक ज़रूरत के हिसाब से बैकएंड को लुकअप कॉल कर सकता है.
    • स्टेट स्टोर: कुछ प्रोसेसिंग फ़्रेमवर्क, बीच के लेवल पर लगातार डेटा उपलब्ध कराते हैं. अगर ऐसा नहीं है, तो राज्यों को अपने हिसाब से सेव करने के लिए, वाहन और इवेंट टाइप के हिसाब से ये यूनीक होने चाहिए. के-वी टाइप की डेटा परसिस्टेंटेंस सेवा के लिए यह सही विकल्प है.
  • सिंक (कस्टम इवेंट): पता लगाई गई स्थिति में हुए बदलाव को, ऐसे किसी भी ऐप्लिकेशन या सेवा के लिए उपलब्ध कराया जाना चाहिए जिसे इससे फ़ायदा मिल सकता है. इसलिए, डाउनस्ट्रीम इस्तेमाल के लिए इस कस्टम इवेंट को इवेंट डिलीवरी सिस्टम पर पब्लिश करना एक सामान्य फ़ैसला है.
  • डाउनस्ट्रीम सेवा: यह कोड, जनरेट किए गए इवेंट का इस्तेमाल करता है और आपके इस्तेमाल के उदाहरण के हिसाब से कार्रवाइयां करता है.

सेवा चुनना

"लास्ट माइल फ़्लीट के लिए रेफ़रंस समाधान" या "ऑन-डिमांड राइड और डिलीवरी के लिए रेफ़रंस समाधान" (यह सुविधा 2023 की तीसरी तिमाही के आखिर में लॉन्च होगी) को लागू करने के लिए, "सोर्स" और "सिंक '' के लिए टेक्नोलॉजी चुनना आसान है. दूसरी ओर, "प्रोसेस जारी है" स्टेटस में कई विकल्प होते हैं. रेफ़रंस समाधान में, Google की ये सेवाएं चुनी गई हैं.

डायग्राम : नीचे दिया गया डायग्राम, रेफ़रंस के लिए सलूशन को लागू करने के लिए Google Cloud की सेवा दिखाता है

फ़्लीट इवेंट के रेफ़रंस वाले समाधान के लिए, बिल्डिंग ब्लॉक

Cloud प्रोजेक्ट का लेआउट

हमारा सुझाव है कि आप डिफ़ॉल्ट रूप से, एक से ज़्यादा प्रोजेक्ट डिप्लॉय करें. ऐसा इसलिए किया जाता है, ताकि Google Maps Platform और Google Cloud के इस्तेमाल को अलग-अलग किया जा सके और उन्हें अपनी पसंद के बिलिंग प्लान से जोड़ा जा सके.

इवेंट का स्रोत

"लास्ट माइल फ़्लीट सलूशन" और "ऑन-डिमांड राइड और डिलीवरी वाला सलूशन", क्लाउड लॉगिंग में एपीआई अनुरोध और रिस्पॉन्स पेलोड लिखते हैं. क्लाउड लॉगिंग की मदद से अपनी पसंद की एक या ज़्यादा सेवाओं के लिए लॉग डिलीवर किए जाते हैं. यहां Cloud Pub/Sub पर रूटिंग करना सबसे सही विकल्प है. इससे, कोडिंग के बिना लॉग को इवेंट स्ट्रीम में बदला जा सकता है.

सिंक

Google Cloud में, Cloud Pub/Sub, मैसेज डिलीवरी का ऐसा सिस्टम है जो रीयल टाइम के करीब काम करता है. जिस तरह सोर्स से मिलने वाले इवेंट Pub/Sub को डिलीवर किए जाते हैं उसी तरह कस्टम इवेंट भी डाउनस्ट्रीम इस्तेमाल के लिए Pub/Sub में पब्लिश किए जाते हैं.

प्रोसेस जारी है

ये कॉम्पोनेंट, इवेंट को प्रोसेस करने में अहम भूमिका निभाते हैं. अन्य बिल्डिंग ब्लॉक की तरह ही, प्रोसेसिंग कॉम्पोनेंट पूरी तरह से सर्वरलेस होते हैं और ये अप और डाउन, दोनों तरह से स्केल करते हैं.

  • शुरुआती रिलीज़ (*) के लिए कंप्यूट प्लैटफ़ॉर्म के तौर पर Cloud Functions
    • यह सर्वरलेस है. साथ ही, लागत को मैनेज करने के लिए, स्केलिंग कंट्रोल की मदद से इसे ऊपर और नीचे स्केल किया जा सकता है
    • फ़्लीट इंजन से जुड़े एपीआई के लिए क्लाइंट लाइब्रेरी की उपलब्धता को देखते हुए, Java को प्रोग्रामिंग भाषा के तौर पर इस्तेमाल किया जाता है. इससे लागू करने में आसानी होती है
  • स्टेटस स्टोर के तौर पर Cloud Firestore का इस्तेमाल करना
    • सर्वरलेस की-वैल्यू स्टोर
  • अपस्ट्रीम और डाउनस्ट्रीम कॉम्पोनेंट के साथ, इंटिग्रेशन पॉइंट के तौर पर Cloud Pub/Sub का इस्तेमाल करना
    • रीयल टाइम के करीब का इंटिग्रेशन, जो ढीले तौर पर जुड़ा हो

फ़ंक्शन का इस्तेमाल डिफ़ॉल्ट सेटिंग के साथ किया जा सकता है. हालांकि, इन्हें फिर से कॉन्फ़िगर भी किया जा सकता है. कॉन्फ़िगरेशन पैरामीटर, डिप्लॉयमेंट स्क्रिप्ट की मदद से सेट किए जाते हैं. साथ ही, इनके बारे में ज़्यादा जानकारी, terraform मॉड्यूल के README में दी गई होती है.

*ध्यान दें: इस रेफ़रंस समाधान में, लागू करने के ऐसे अन्य तरीके रिलीज़ करने की योजना है जिनसे अलग-अलग ज़रूरतों को पूरा करने में मदद मिल सकती है.

डिप्लॉयमेंट

रेफ़रंस सलूशन को डिप्लॉय करने की प्रोसेस को दोहराया जा सके, उसे पसंद के मुताबिक बनाया जा सके, सोर्स कोड को कंट्रोल किया जा सके, और उसे सुरक्षित रखा जा सके, इसके लिए Terraform को ऑटोमेशन टूल के तौर पर चुना गया है. Terraform, IaC (Infrastructure as Code) टूल है. इसका इस्तेमाल बहुत से लोग करते हैं. इसमें Google Cloud के लिए बेहतर सहायता मिलती है.

Terraform मॉड्यूल

एक बड़ा मोनोलिथिक रेफ़रंस सलूशन डिप्लॉयमेंट मॉड्यूल बनाने के बजाय, ऑटोमेशन के फिर से इस्तेमाल किए जा सकने वाले ब्लॉक को Terraform मॉड्यूल के तौर पर लागू किया जाता है. इनका इस्तेमाल अलग से किया जा सकता है. मॉड्यूल में, कॉन्फ़िगर किए जा सकने वाले कई वैरिएबल होते हैं. इनमें से ज़्यादातर वैरिएबल की डिफ़ॉल्ट वैल्यू होती हैं, ताकि आप तुरंत काम शुरू कर सकें. साथ ही, अपनी ज़रूरतों और प्राथमिकताओं के हिसाब से, इन्हें अपनी पसंद के मुताबिक बनाया जा सकता है.

रेफ़रंस सलूशन में शामिल मॉड्यूल:

  • फ़्लीट इंजन लॉगिंग कॉन्फ़िगरेशन: Fleet Engine के साथ इस्तेमाल करने के लिए, क्लाउड लॉगिंग से जुड़े कॉन्फ़िगरेशन को ऑटोमेट करें. रेफ़रंस समाधान में, इसका इस्तेमाल, Fleet Engine से जुड़े लॉग को किसी खास Pub/Sub विषय पर भेजने के लिए किया जाता है.
  • Fleet Events क्लाउड फ़ंक्शन डिप्लॉयमेंट: इसमें सैंपल फ़ंक्शन कोड डिप्लॉयमेंट शामिल होता है. साथ ही, यह सुरक्षित क्रॉस-प्रोजेक्ट इंटिग्रेशन के लिए ज़रूरी अनुमति सेटिंग के ऑटोमेशन को भी मैनेज करता है.
  • पूरे रेफ़रंस सलूशन का डिप्लॉयमेंट: पिछले दो मॉड्यूल को कॉल करता है और पूरे समाधान को रैप करता है.

सुरक्षा

आईएएम को, कम से कम विशेषाधिकार के सिद्धांतों के साथ-साथ, Google Cloud की सुरक्षा से जुड़े सबसे सही तरीकों को लागू करने के लिए अपनाया जाता है. जैसे, सेवा खाते के नाम पर काम करना. Google Cloud, सुरक्षा पर ज़्यादा कंट्रोल देने के लिए क्या-क्या ऑफ़र करता है, यह बेहतर तरीके से समझने के लिए नीचे दिए गए लेख पढ़ें.

अगली कार्रवाइयां

अब आपके पास फ़्लीट इवेंट के रेफ़रंस के लिए समाधान को ऐक्सेस करने और उसे एक्सप्लोर करने का विकल्प है. शुरू करने के लिए, GitHub पर जाएं.

अन्य जानकारी

ज़रूरी शर्तें इकट्ठा करना

हमारा सुझाव है कि आप इस प्रोसेस में शामिल होने से पहले, अपनी ज़रूरी शर्तों को इकट्ठा कर लें.

सबसे पहले, यह जानकारी कैप्चर करें कि आपको दिलचस्पी क्यों है या करीब-करीब रीयल टाइम इवेंट का इस्तेमाल क्यों करना चाहिए. यहां कुछ सवाल दिए गए हैं, जिनसे आपको अपनी ज़रूरतों को समझने में मदद मिलेगी.

  • इवेंट स्ट्रीम के काम का होने के लिए कौनसी जानकारी देना ज़रूरी है?
    • क्या नतीजा, पूरी तरह से Google की सेवाओं में कैप्चर किए गए या जनरेट किए गए डेटा से मिल सकता है? इसके अलावा, क्या इंटिग्रेट किए गए बाहरी सिस्टम के साथ डेटा को बेहतर बनाना ज़रूरी है? अगर हां, तो वे सिस्टम क्या हैं और वे कौनसे इंटिग्रेशन इंटरफ़ेस उपलब्ध कराते हैं?
    • आपको कारोबार के तौर पर कौनसी मेट्रिक मेज़र करनी हैं? इन्हें कैसे परिभाषित किया जाता है?
    • अगर आपको सभी इवेंट के लिए मेट्रिक का हिसाब लगाना है, तो इसके लिए किस तरह के एग्रीगेशन की ज़रूरत होगी? सिलसिलेवार तरीके से निर्देश दें. (उदा. सीमित संसाधनों के तहत परफ़ॉर्मेंस का आकलन करने के लिए, भीड़-भाड़ वाले समय के दौरान, फ़्लीट के किसी सब-सेक्ट में ईटीए/एटीए की तुलना करें.
  • आपको बैच के बजाय, इवेंट पर आधारित मॉडल में दिलचस्पी क्यों है? क्या यह कम इंतज़ार (कार्रवाई में लगने वाला समय) के लिए है या ढीले तौर पर जुड़े इंटिग्रेशन (Agility) के लिए है?
    • अगर लाइव स्ट्रीमिंग करने और उसके दिखने के बीच इंतज़ार का समय कम है, तो "कम" बताएं. मिनट? सेकंड? सब-सेकंड? और रिस्पॉन्स में लगने वाला समय कितना है?
  • क्या आपने पहले से ही, टीम के तौर पर टेक्नोलॉजी स्टैक और उससे जुड़ी स्किल में निवेश किया है? अगर हां, तो यह क्या है और यह कौनसे इंटिग्रेशन पॉइंट उपलब्ध कराता है?
    • क्या आपके मौजूदा सिस्टम, ज़रूरी शर्तों को पूरा नहीं कर सकते या आपके फ़्लीट से आने वाले इवेंट को प्रोसेस करने में उन्हें परेशानी हो सकती है?

डिज़ाइन से जुड़े सिद्धांत

किसी भी काम को करने के लिए, कोई रणनीति बनाना हमेशा फ़ायदेमंद होता है. इससे, डिज़ाइन से जुड़े एक जैसे फ़ैसले लेने में मदद मिलती है. खास तौर पर, जब आपके पास चुनने के लिए कई विकल्प हों.

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

स्ट्रीमिंग से जुड़े सिद्धांत

अगर आपने इवेंट के आधार पर या स्ट्रीमिंग की सुविधा का इस्तेमाल हाल ही में शुरू किया है, तो कुछ अहम कॉन्सेप्ट के बारे में जानना ज़रूरी है. इनमें से कुछ कॉन्सेप्ट, बैच प्रोसेसिंग से काफ़ी अलग हो सकते हैं.

  • स्केल करें : बैच प्रोसेसिंग के उलट, जहां आपके पास आम तौर पर इस बात का अच्छा आइडिया होता है कि स्ट्रीमिंग में कितने डेटा को प्रोसेस करना है. किसी शहर में ट्रैफ़िक जाम होने पर, किसी इलाके से अचानक बहुत सारे इवेंट जनरेट हो सकते हैं. ऐसे में, आपको इन्हें प्रोसेस करना होगा.
  • विंडो : अक्सर, इवेंट को एक-एक करके प्रोसेस करने के बजाय, इन्हें एक टाइमलाइन पर छोटी "विंडो" में ग्रुप किया जाता है, ताकि इन्हें आसानी से कैलकुलेट किया जा सके. विंडो से जुड़ी कई रणनीतियां हैं, जैसे कि "तय विंडो (उदाहरण के लिए, हर कैलेंडर दिन)", "स्लाइडिंग विंडो (पिछले पांच मिनट)", "सेशन विंडो (इस ट्रिप के दौरान)". इनमें से आपको कोई एक चुनना चाहिए. यह अवधि जितनी लंबी होगी, नतीजे देने में उतनी ही ज़्यादा देरी होगी. अपनी ज़रूरतों के हिसाब से सही मॉडल और कॉन्फ़िगरेशन चुनें.
  • ट्रिगर करना : कुछ मामलों में, आपके पास ज़्यादा समय वाली विंडो सेट करने के अलावा कोई विकल्प नहीं होता. हालांकि, आपको इवेंट जनरेट करने के लिए, विंडो के आखिर तक इंतज़ार नहीं करना है. इसके बजाय, आपको बीच-बीच में नतीजे दिखाने हैं. इस कॉन्सेप्ट को उन इस्तेमाल के उदाहरणों के लिए लागू किया जा सकता है जहां पहले तुरंत नतीजे दिखाने और बाद में उन्हें ठीक करने में यह मददगार हो. कल्पना करें कि किसी डिलीवरी के 25%, 50%, 75% पूरे होने के बाद, इंटरमीडिएट स्टेटस दिख रहा है.
  • क्रम : ज़रूरी नहीं है कि इवेंट, सिस्टम में उसी क्रम में पहुंचें जिस क्रम में उन्हें जनरेट किया गया था. खास तौर पर, मोबाइल नेटवर्क पर कम्यूनिकेशन के इस्तेमाल के उदाहरणों के लिए, जो देरी और रूटिंग पाथ को जटिल बनाते हैं. आपको "इवेंट के होने का समय" (जब इवेंट असल में हुआ) और "प्रोसेस का समय" (जब इवेंट सिस्टम में पहुंचा) के बीच के अंतर के बारे में पता होना चाहिए. साथ ही, इवेंट को उसी हिसाब से मैनेज करना चाहिए. आम तौर पर, आपको "इवेंट के समय" के आधार पर इवेंट प्रोसेस करने होते हैं.
  • मैसेज डिलीवरी - कम से कम एक बार बनाम एक बार: अलग-अलग इवेंट प्लैटफ़ॉर्म पर, इनके लिए अलग-अलग सुविधाएं उपलब्ध होती हैं. अपने इस्तेमाल के उदाहरण के आधार पर, आपको फिर से कोशिश करने या डुप्लीकेट कॉपी हटाने की रणनीतियों पर विचार करना होगा.
  • पूरी जानकारी : ऑर्डर में बदलाव करने की तरह ही, मैसेज मिटने का भी खतरा होता है. ऐसा डिवाइस की बैटरी लाइफ़, फ़ोन को अनजाने में होने वाले नुकसान, टनल में होने पर इंटरनेट कनेक्शन टूटने या मैसेज मिलने के बाद, उसे स्वीकार करने की समयसीमा खत्म होने की वजह से हो सकता है. डेटा पूरा न होने से आपके नतीजों पर क्या असर पड़ेगा?

यह पूरी सूची नहीं है, बल्कि सिर्फ़ एक जानकारी है. यहां कुछ ऐसी किताबों के बारे में बताया गया है जिन्हें पढ़ने का सुझाव दिया जाता है. इनसे आपको इन विषयों के बारे में ज़्यादा जानकारी मिलेगी.

योगदानकर्ता

Google इस दस्तावेज़ का रखरखाव करता है. मूल रूप से इन योगदान देने वालों ने इसे लिखा है.

मुख्य लेखक: