रियल-टाइम फ्रंटएंड टेलीमेट्री प्लेटफ़ॉर्म

समस्या

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

तरीका

• छोटा, टाइप वाला SDK। एक TypeScript ट्रैकर हर स्क्रीन और प्लेटफ़ॉर्म पर उपयोगकर्ता की क्रियाओं का एक जैसा डेटा इकट्ठा करता था, इसलिए एक इवेंट का मतलब हर जगह एक ही रहता था।
• सुरक्षा वाल्व के साथ थ्रॉटलिंग। SDK इवेंट को बैच में जमा करता है और छोटे टाइमर या आकार की सीमा में से जो पहले आए, उस पर भेज देता है। हर क्लिक पर एक रिक्वेस्ट ब्राउज़र के नेटवर्क थ्रेड को भूखा कर देती है; इवेंट को ज़्यादा देर रोकने पर टैब बंद होते समय खोने का जोखिम रहता है, इसलिए पेज बंद होते समय navigator.sendBeacon इस्तेमाल होता है।
• वैलिडेट करने वाला BFF। बैच एक Backend for Frontend तक पहुँचते हैं, जो TypeScript परिभाषाओं के मुकाबले स्कीमा जाँचता है, टाइमस्टैंप की तर्कसंगतता देखता है, अनपेक्षित फ़ील्ड और निजी डेटा हटाता है, और सेशन मेटाडेटा जोड़ता है। बैकएंड के फ़ैसले की तुलना UI में दिखी चीज़ से करने पर दोनों के बीच के स्टेट मिसमैच सामने आए।
• कॉलम-आधारित स्टोरेज में स्ट्रीमिंग पाइपलाइन। स्ट्रीमिंग ट्रैफ़िक के उछाल को सोख लेती है, और कॉलम-आधारित स्टोरेज बहुत बड़े, ऊँची कार्डिनैलिटी वाले इवेंट सेट पर एग्रीगेशन मिलीसेकंड में कर देता है, जबकि रो-आधारित स्टोर धीमे पड़ जाते हैं।
• चुपचाप विफलता संभालना। अगर पाइपलाइन बंद हो, तो SDK लोकल में एक छोटा बफ़र रखता है और एक निष्क्रिय सर्किट ब्रेकर भेजना रोक देता है। वह सेहत जाँचने के लिए सर्वर को पिंग नहीं करता; वह अगली सफल प्रतिक्रिया का इंतज़ार करता है।

नतीजा

घटना का पता लगाने का समय दिनों से घटकर 5 मिनट से कम हो गया। जब एक टूटे चरण का मतलब ढेर सारी नाकाम कोशिशें होता है, तो यही फ़र्क है पोस्टमॉर्टम के एक नोट और उसी सुबह हुए सुधार के बीच।