हर कोई रियल-टाइम अपडेट चाहता है जब तक उन्हें यह एहसास नहीं होता कि "तेज़" और "सही" एक ही चीज़ नहीं हैं। एक डिस्ट्रिब्यूटेड सिस्टम (distributed system) में, इवेंट्स प्रकाश की गति से यात्रा कर सकते हैं और फिर भी गलत क्रम में पहुँच सकते हैं। WebSockets डिस्कनेक्ट होकर फिर से जुड़ जाते हैं। Message brokers पैकेट को दोबारा भेजते हैं। Background workers टाइमआउट कैंसलेशन के खिलाफ दौड़ते हैं। परिणाम? एक क्लाइंट इवेंट 42 देख सकता है, फिर इवेंट 40, और फिर एक स्नैपशॉट जो दावा करता है कि सिस्टम पहले से ही इवेंट 45 पर है। यदि आप लंबे समय तक चलने वाले एजेंट वर्कफ़्लो (agent workflows) बना रहे हैं, तो वह अराजकता कोई 'एज केस' (edge case) नहीं है। यह एक आधारभूत वास्तविकता (baseline) है। डिलीवरी से मिलीसेकंड बचाने की चिंता करने से पहले अपने इवेंट्स के क्रम को ठीक करें।
"रियल-टाइम" की जटिल वास्तविकता
रियल-टाइम एक ट्रांसपोर्ट प्रॉपर्टी (transport property) है। यह बताता है कि एक पैकेट तार के माध्यम से कितनी तेज़ी से चलता है, न कि यह कि उसके द्वारा बताई गई कहानी का कोई अर्थ है या नहीं। लंबे समय तक चलने वाले कार्य हर विसंगति को बढ़ा देते हैं क्योंकि वे समय के साथ फैलते हैं। एक मॉडल ट्रेनिंग जॉब, एक मल्टी-स्टेप अप्रूवल फ्लो, या एक वीडियो रेंडरिंग पाइपलाइन मिनटों या घंटों में दर्जनों इवेंट्स जारी कर सकती है। उस दौरान, कुछ भी गलत हो सकता है।
एक ब्रोकर किसी मैसेज को दोबारा भेज सकता है क्योंकि उसका एक्नॉलेजमेंट (acknowledgement) खो गया हो। एक लोड बैलेंसर दो इवेंट्स को अलग-अलग नेटवर्क पाथ पर रूट कर सकता है, जिससे नया वाला पहले पहुँच जाए। एक वर्कर प्रोसेस डेटाबेस में लिखने के बाद लेकिन सफलता का इवेंट पब्लिश करने से पहले मर सकता है, और फिर दूसरा वर्कर उस कार्य को उठाकर अपना स्वयं का प्रोग्रेस इवेंट जारी कर सकता है। यदि आपका फ्रंटएंड यह मान लेता है कि नवीनतम मैसेज ही सबसे सटीक मैसेज है, तो वह एक ऐसी स्थिति (state) दिखाएगा जो कभी अस्तित्व में ही नहीं थी। उपयोगकर्ता "completed" बैज को वापस "processing" पर बदलते हुए देखेंगे, या इससे भी बुरा, एक रद्द किया गया कार्य अचानक फिर से जीवित हो जाएगा। बिना क्रम के गति केवल उच्च फ्रेम रेट पर होने वाला भ्रम है।
सीक्वेंस नंबर ही असली घड़ी हैं
इसका समाधान प्रोड्यूसर (producer) द्वारा जेनरेट किए गए सख्त, मोनोटोनिक सीक्वेंस नंबर (monotonic sequence numbers) हैं। स्टेट बदलने वाले हर ऑपरेशन को एक नंबर मिलता है जो ठीक एक से बढ़ता है, बिना किसी गैप और बिना किसी रोलबैक के। वह नंबर उसी ट्रांजेक्शन के साथ सुरक्षित (persist) किया जाना चाहिए जिसमें इवेंट स्वयं है। यदि डेटाबेस रो अपडेट होती है लेकिन सीक्वेंस कमिट विफल हो जाता है, तो आप दोनों को रोलबैक कर दें। यह लॉजिकल टाइमलाइन को स्टेट चेंज के साथ एटॉमिक (atomic) रखता है।
इवेंट आईडी (Event IDs) अभी भी उपयोगी हैं, लेकिन वे एक अलग समस्या का समाधान करते हैं। एक इवेंट आईडी एक विशिष्ट पेलोड (payload) की पहचान करती है ताकि जब ब्रोकर एक ही मैसेज को दो बार डिलीवर करे तो आप उसे डुप्लिकेट होने से बचा सकें (deduplicate)। दूसरी ओर, एक सीक्वेंस नंबर आपको बताता है कि वह पेलोड कॉज़ल चेन (causal chain) में कहाँ आता है। यह गैप्स को उजागर करता है। यह क्रम को उजागर करता है। टाइमस्टैम्प (timestamp) इनमें से कुछ भी नहीं करता। क्लॉक्स ड्रिफ्ट (clocks drift) करते हैं, NTP पीछे चला जाता है, और वर्चुअल मशीनें रुक जाती हैं। टाइमस्टैम्प का उपयोग केवल डिस्प्ले उद्देश्यों के लिए करें, जैसे कि "3 मिनट पहले शुरू हुआ," और कभी भी बिजनेस लॉजिक के लिए सॉर्टिंग की (sorting key) के रूप में नहीं।
क्लाइंट को स्ट्रीम को कैसे संभालना चाहिए
एक बार जब प्रोड्यूसर एक मोनोटोनिक सीक्वेंस की गारंटी दे देता है, तो कंज्यूमर (consumer) के लिए नियम सरल और सख्त हो जाते हैं। यदि इनबाउंड सीक्वेंस नंबर पिछले लागू किए गए नंबर के बराबर या उससे कम है, तो उसे छोड़ दें। यह या तो डुप्लिकेट है या एक पुराना लेटकमर (latecomer) है। यदि सीक्वेंस पिछले लागू किए गए नंबर से ठीक एक अधिक है, तो उसे तुरंत लागू करें। यह 'हैप्पी पाथ' (happy path) है। यदि सीक्वेंस आगे कूद जाता है, मान लीजिए आपने 12 की उम्मीद की थी लेकिन 15 प्राप्त किया, तो कुछ गायब है। नए इवेंट को बफर करें और सर्वर से अगले अपेक्षित सीक्वेंस से शुरू होने वाले रीप्ले (replay) के लिए पूछें। अंदाज़ा न लगाएं। यह उम्मीद न करें कि गैप मायने नहीं रखेगा और आगे न बढ़ें।
टर्मिनल स्टेट्स (Terminal states) को अपरिवर्तनीय (irrevocable) माना जाना चाहिए। एक बार जब किसी कार्य को 'completed', 'failed', या 'cancelled' के रूप में चिह्नित कर दिया जाता है, तो क्लाइंट को उस ऑपरेशन के लिए किसी भी बाद के स्टेट चेंज को अस्वीकार कर देना चाहिए। यह तब तक स्पष्ट लगता है जब तक आप