जोपर्यंत लोकांना हे उमजत नाही की "वेगवान" (fast) आणि "अचूक" (correct) या दोन वेगळ्या गोष्टी आहेत, तोपर्यंत प्रत्येकाला रिअल-टाइम अपडेट्स हवे असतात. डिस्ट्रिब्युटेड सिस्टममध्ये (distributed system), इव्हेंट्स प्रकाशाच्या वेगाने प्रवास करू शकतात तरीही ते चुकीच्या क्रमाने येऊ शकतात. WebSockets डिस्कनेक्ट होतात आणि पुन्हा कनेक्ट होतात. Message brokers पॅकेट्स पुन्हा पाठवतात. Background workers टाइमआउट कॅन्सलेशनच्या शर्यतीत असतात. परिणाम? क्लायंटला आधी इव्हेंट ४२, मग इव्हेंट ४०, आणि त्यानंतर असा स्नॅपशॉट दिसू शकतो की सिस्टम आधीच इव्हेंट ४५ वर पोहोचली आहे. जर तुम्ही दीर्घकाळ चालणारे (long-running) एजंट वर्कफ्लो तयार करत असाल, तर हा गोंधळ केवळ एखादी दुर्मिळ घटना (edge case) नसून तो एक सामान्य भाग (baseline) आहे. डिलिव्हरीचा वेळ काही मिलिसेकंद कमी करण्याच्या चिंतेपूर्वी तुमच्या इव्हेंट्सचा क्रम (order) नीट करा.

"रिअल-टाइम"चे विस्कळीत वास्तव

रिअल-टाइम ही ट्रान्सपोर्टची (transport) प्रॉपर्टी आहे. ती एखादे पॅकेट वायरवरून किती वेगाने प्रवास करते हे सांगते, त्यातून मिळणारी माहिती अर्थपूर्ण आहे की नाही हे नाही. दीर्घकाळ चालणाऱ्या कामांमुळे प्रत्येक विसंगती अधिक स्पष्टपणे जाणवते कारण ती वेळेच्या व्याप्तीवर पसरलेली असते. मॉडेल ट्रेनिंग जॉब, मल्टी-स्टेप अप्रूव्हल फ्लो किंवा व्हिडिओ रेंडरिंग पाइपलाइन काही मिनिटे किंवा तासांच्या दरम्यान डझनभर इव्हेंट्स तयार करू शकतात. त्या काळात काहीही चुकीचे घडू शकते.

एखादा ब्रोकर (broker) मेसेजचा ॲक्नॉलेजमेंट (acknowledgement) हरवल्यामुळे तो मेसेज पुन्हा पाठवू शकतो. लोड बॅलन्सर (load balancer) दोन इव्हेंट्सना वेगवेगळ्या नेटवर्क मार्गांनी पाठवू शकतो, ज्यामुळे नवीन इव्हेंट आधी पोहोचू शकतो. एखादा वर्कर प्रोसेस डेटाबेसमध्ये माहिती लिहिल्यानंतर पण 'सक्सेस इव्हेंट' पब्लिश करण्यापूर्वीच बंद पडू शकतो, आणि त्यानंतर दुसरा वर्कर तेच काम उचलून स्वतःची प्रगती (progress) कळवू शकतो. जर तुमच्या फ्रंटएंडने (frontend) शेवटचा मेसेज हा सर्वात अचूक मेसेज आहे असे मानले, तर ते असे स्टेट (state) दाखवेल जे प्रत्यक्षात कधीच अस्तित्वात नव्हते. युजर्सना 'completed' बॅज अचानक 'processing' मध्ये बदलताना दिसेल, किंवा त्याहून वाईट म्हणजे, एखादे रद्द केलेले काम अचानक पुन्हा सुरू झाल्यासारखे वाटेल. क्रमनुसार नसलेला वेग म्हणजे केवळ उच्च फ्रेम रेटवर असलेला गोंधळ आहे.

सिक्वेन्स नंबर्स (Sequence Numbers) हेच खरे घड्याळ आहेत

याचे निराकरण म्हणजे प्रोड्युसरद्वारे (producer) तयार केलेले कडक, मोनोटोनिक (monotonic) सिक्वेन्स नंबर्स. स्टेट बदलणाऱ्या प्रत्येक ऑपरेशनला एक नंबर दिला जातो जो कोणताही गॅप किंवा रोलबॅक न ठेवता नेमका एकने वाढतो. तो नंबर त्याच ट्रान्झॅक्शनमध्ये (transaction) सेव्ह केला पाहिजे ज्यामध्ये इव्हेंट आहे. जर डेटाबेस रो अपडेट झाली पण सिक्वेन्स कमिट (commit) अयशस्वी झाली, तर दोन्ही गोष्टी रोलबॅक करा. यामुळे लॉजिकल टाइमलाइन स्टेट बदलासोबत अ‍ॅटॉमिक (atomic) राहते.

इव्हेंट आयडी (Event IDs) अजूनही उपयुक्त आहेत, पण ते वेगळी समस्या सोडवतात. इव्हेंट आयडी एका विशिष्ट पेलोडची (payload) ओळख पटवतो, जेणेकरून ब्रोकरने तोच मेसेज दोनदा पाठवल्यास तुम्ही ड्युप्लिकेट टाळू शकता. दुसरीकडे, सिक्वेन्स नंबर तुम्हाला सांगतो की तो पेलोड कॉझल चेनमध्ये (causal chain) कुठे आहे. तो गॅप्स आणि क्रम स्पष्ट करतो. टाइमस्टॅम्प (timestamp) या दोन्ही गोष्टी करू शकत नाही. घड्याळे मागे-पुढे होतात, NTP मागे जाते आणि व्हर्च्युअल मशीन्स (virtual machines) थांबतात. टाइमस्टॅम्पचा वापर फक्त प्रदर्शनासाठी (display purposes) करा, जसे की "३ मिनिटांपूर्वी सुरू झाले," आणि बिझनेस लॉजिकसाठी सॉर्टिंग की (sorting key) म्हणून कधीही वापरू नका.

क्लायंटने स्ट्रीम कशी हाताळली पाहिजे

एकदा का प्रोड्युसरने मोनोटोनिक सिक्वेन्सची खात्री दिली की, कंज्युमरला (consumer) साधे आणि कडक नियम मिळतात. जर येणारा सिक्वेन्स नंबर शेवटच्या लागू केलेल्या नंबरपेक्षा कमी किंवा समान असेल, तर तो काढून टाका. तो एकतर ड्युप्लिकेट आहे किंवा जुना झालेला मेसेज आहे. जर सिक्वेन्स शेवटच्या लागू केलेल्या नंबरपेक्षा नेमका एकने मोठा असेल, तर तो लगेच लागू करा. हा 'हॅपी पाथ' (happy path) आहे. जर सिक्वेन्स पुढे उडी मारत असेल, समजा तुम्हाला १२ अपेक्षित होते पण १५ मिळाले, तर काहीतरी गहाळ आहे. नवीन इव्हेंट बफर (buffer) करा आणि सर्व्हरला पुढच्या अपेक्षित सिक्वेन्सपासून पुन्हा प्ले (replay) करण्यास सांगा. अंदाज लावू नका. गॅप महत्त्वाचा नसेल या आशेने पुढे जाऊ नका.

टर्मिनल स्टेट्सना (Terminal states) अपरिवर्तनीय मानले पाहिजे. एकदा का एखादे काम 'completed', 'failed' किंवा 'cancelled' म्हणून मार्क केले गेले की, क्लायंटने त्या ऑपरेशनसाठी त्यानंतर होणारे कोणतेही स्टेट बदल नाकारले पाहिजेत. हे ऐकायला साधे वाटते, जोपर्यंत तुम्ही...