Fleet Engine के रीयल-टाइम इवेंट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सेवा चुनना

"Last Mile Fleet Solution" या "मांग पर राइड और डिलीवरी सलूशन" (2023 की तीसरी तिमाही के आखिर में लॉन्च होने वाला है) के लिए रेफ़रंस सलूशन लागू करने की बात आती है, तो "सोर्स" और "सिंक" के लिए टेक्नोलॉजी चुनना आसान होता है. वहीं, "प्रोसेसिंग" में कई विकल्प होते हैं. रेफ़रंस सलूशन ने Google की इन सेवाओं को चुना है.

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

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

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

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

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

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

सिंक

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

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

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

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

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

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

डिप्लॉयमेंट

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

Terraform मॉड्यूल

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

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

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

सुरक्षा

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

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

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

अपेंडिक्स

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

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

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

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

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

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

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

स्ट्रीमिंग से जुड़े कॉन्सेप्ट

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

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

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

योगदानकर्ता

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

मुख्य लेखक: