ऐसे सिंक के छह नियम जो तब चलता है जब कोई देख नहीं रहा

8 अक्टूबर 2026 को Lance Martin और CJ Avilla ने एक एजेंट का वॉकथ्रू पब्लिश किया जो हर सुबह Slack और GitHub पढ़ता है और Slack में एक ब्रीफ़ पोस्ट करता है. उसे चलते हुए कोई नहीं देखता. उनका सबसे काम का पैराग्राफ़ उस फ़ेलियर के बारे में है जो सफलता जैसा दिखता है. जब किसी सोर्स का सर्वर बंद हो या उसका टोकन एक्सपायर हो गया हो, तो “एजेंट को उस सोर्स से कुछ नहीं दिखता और वह ‘कुछ नया नहीं’ रिपोर्ट करता है.”

Shopify से Brevo तक का कॉन्टैक्ट सिंक भी इसी फ़ेलियर से गुज़रता है. दो SaaS टूल्स के बीच हर शेड्यूल्ड सिंक भी. चुपचाप फ़ेल होने वाला रीड बिल्कुल वैसा दिखता है जैसे किसी स्टोर में आज किसी ने साइन अप ही न किया हो.

उनका लेख बिना निगरानी चलने वाले एजेंट के छह नियमों पर ख़त्म होता है. उन्हें सिंक चलाने वाले की नज़र से पढ़ें, तो हर नियम reverse ETL का नियम है. वर्कर बंद हो गया. सिंक नहीं रुका. एक क्रैश के दौरान एक कॉन्टैक्ट का पीछा करता है. यह पेज उसके ऊपर की चेकलिस्ट है: ऑटोमेटेड डेटा सिंक के छह नियम, आज Tajo का रनर हर नियम के लिए क्या करता है, और वह कहाँ पीछे रह जाता है. रनर का पक्ष अटके या फ़ेल हुए सिंक को बहाल करें में लिखा है.

1. बुकमार्क से पढ़ें, और उसे तभी आगे बढ़ाएँ जब बैच पहुँच जाए

उनका पहला नियम: “हर सोर्स को बुकमार्क से पढ़ें, तय समय-खिड़की से नहीं.” “पिछले 24 घंटे” वाली खिड़की रन देर से शुरू होने पर गैप छोड़ती है और जल्दी शुरू होने पर रिकॉर्ड दोहराती है.

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

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

क़ीमत यह है कि टूटा हुआ बैच दो बार पढ़ा जाता है. नियम 2 इसे सुरक्षित बनाता है.

2. हर राइट को ऐसी कुंजी दें जो क्रैश के बाद भी बची रहे

उनका चौथा नियम पोस्ट को भेजा हुआ “तभी मानता है जब Slack पुष्टि करे”, और तभी बुकमार्क और लेजर अपडेट करता है. रजिस्टर्ड चिट्ठी इसी तरह काम करती है. वह तब पहुँची मानी जाती है जब साइन की हुई रसीद लौटती है, तब नहीं जब वह काउंटर से निकलती है.

Tajo किसी रिकॉर्ड को लिखे, उससे पहले रिकॉर्ड को एक डिलीवरी कुंजी मिलती है. कुंजी सिंक, सोर्स, पेज कर्सर, पेज पर जगह और ख़ुद रिकॉर्ड का हैश है, इसलिए उसमें कोई निजी डेटा नहीं होता. डेस्टिनेशन को कॉल करने से पहले उसे क्लेम किया जाता है और राइट सफल होने पर पूरा मार्क किया जाता है. पूरी हुई कुंजियाँ सात दिन तक रखी जाती हैं. रीट्राई, या बाद का शेड्यूल्ड रन, उसी रिकॉर्ड के लिए वही कुंजी बनाता है, उसे पूरा पाता है और डेस्टिनेशन को दोबारा कॉल नहीं करता.

इसके साथ दो क़ीमतें आती हैं. सात दिन बाद लेजर भूल जाता है, और किसी पुराने कर्सर से रीप्ले फिर से लिख सकता है. और जो राइट टाइम आउट हो जाता है, वह एक वाजिब शक छोड़ता है: हो सकता है दूसरे सिस्टम ने उसे सेव कर लिया हो पर जवाब न दिया हो. Tajo उस राइट को सात दिन के लिए फ़ेल दर्ज करने के बजाय अगले अटेम्प्ट में फिर से आज़माता है. जो कनेक्टर डेस्टिनेशन को अपनी idempotency कुंजी देता है, वह यह शक ख़त्म कर देता है. जो ऐसा नहीं कर सकता, उसके साथ एक डुप्लिकेट की संभावना बनी रहती है.

3. एक रन सिंक का मालिक है, और हर राइट से पहले यह साबित करता है

उनका तीसरा नियम: “पोस्ट करने से ठीक पहले हर आइटम दोबारा जाँचें.” सिंक में, रीड और राइट के बीच जिस चीज़ के बदलने की सबसे ज़्यादा संभावना है, वह है कि लिखने की अनुमति किसके पास है.

Tajo के हर सिंक की एक लीज़ होती है, जिसका अपना टोकन होता है और 15 मिनट की उम्र जो हर पाँच मिनट में रिन्यू होती है. रन डेस्टिनेशन को कॉल करने से पहले जाँचता है कि लीज़ अब भी उसके पास है, और कर्सर आगे बढ़ाने से पहले फिर जाँचता है. जिस रन ने लीज़ खो दी, वह रुक जाता है, और उसके पेज पर लिखा होता है “रन ने बीच में अपना स्लॉट खो दिया और दो बार लिखने से बचने के लिए रुक गया।” किसी चल रहे रन से टकराने वाला दूसरा रन उसके पीछे क़तार में लगने के बजाय ख़त्म हो जाता है.

रिकॉर्ड भी जाँचे जाते हैं. रीड और राइट के बीच, रिकॉर्ड सहमति फ़िल्टर से गुज़रते हैं. बिना साबित सहमति के किसी मार्केटिंग ऑडियंस में लिखा जाने वाला कॉन्टैक्ट अंदाज़ा लगाने के बजाय अस्वीकार कर दिया जाता है. हेल्प पेज के शब्दों में, फ़ेलियर मोड “बहुत सतर्क” होता है, कभी “ज़्यादा भेजा” नहीं.

4. जो गुज़र जाने वाला है उसे दोबारा आज़माएँ, जो नहीं है उसे रोकें

उनके छह नियम इस बारे में कुछ नहीं कहते कि कितनी बार दोबारा कोशिश करें. सिंक को यह नियम चाहिए, क्योंकि उसके सबसे आम फ़ेलियर हैं रेट लिमिट और वेंडर का एक बुरा मिनट.

Tajo का क़तार में लगा रन फ़ेल हो, तो उसे पाँच अटेम्प्ट मिलते हैं. उनके बीच इंतज़ार 60, 120, 240 और 480 सेकंड है, कुल मिलाकर लगभग पंद्रह मिनट. कुछ फ़ेलियर कभी रीट्राई नहीं होते, क्योंकि दोबारा कोशिश उन्हें ठीक नहीं कर सकती. जो रन पहले से चल रहे रन से टकराया, वह रीट्राई नहीं होता, और न वह रन जिसका पब्लिश किया गया वर्शन या कनेक्शन अब वैध नहीं हैं.

लगातार फ़ेल होना एक बार की चूक से अलग है. अगर सिंक में आख़िरी बदलाव के बाद पूरे हुए आख़िरी पाँच रन सभी फ़ेल हुए, तो Tajo सिंक को पॉज़ कर देता है और उसके पेज पर आख़िरी एरर दिखाता है. एक सफलता गिनती को रीसेट कर देती है. पॉज़ किया गया सिंक अपने आप दोबारा शुरू नहीं होता; कोई व्यक्ति कारण ठीक करता है और उसे फिर से पब्लिश करता है. वर्कर वाला लेख उस घटना को बताता है जिससे यह नियम बना.

5. चुप्पी को एक नतीजा मानें

“फ़ेल रीड को न पढ़ा जा सकने वाला बताएँ, कभी शांत दिन नहीं.” छह में यह सबसे कठिन है, और अकेला ऐसा जिसे हम सिर्फ़ आंशिक रूप से पूरा करते हैं.

जहाँ यह लागू होता है: एरर देने वाला रीड रन को फ़ेल कर देता है. अस्वीकार किया गया टोकन या जवाब न देने वाला सर्वर डेस्टिनेशन को कुछ नहीं भेजता, कर्सर को वहीं छोड़ता है जहाँ वह था, और पाँच फ़ेल रन के बाद होने वाले पॉज़ में गिना जाता है. और हर घंटे, 13 मिनट पर, Tajo एक्टिव सिंक वाले हर वर्कस्पेस को जाँचता है. पिछले 24 घंटों में कोई सफल रन न होने पर वह अपनी टीम को अलर्ट करता है, उस वर्कस्पेस के लिए भी जहाँ कोई रन दर्ज ही नहीं हुआ. यही हर घंटे की जाँच है.

जहाँ लागू नहीं होता: लेखक जिस शांत रीड की बात करते हैं, वह ऐसा रीड है जो बिना किसी रिकॉर्ड के “OK” जवाब देता है. हमारा रनर उसे सफलता गिनता है. Shopify ग्राहकों जैसे सोर्स के लिए, एक अलग जाँच Tajo की टीम को लगातार दस सफल रन शून्य रिकॉर्ड के साथ होने पर चेतावनी देती है, अगर सिंक ने पहले रिकॉर्ड दिए थे. Shopify ऑर्डर अपडेट समय से पढ़े जाते हैं, इसलिए वहाँ ख़ाली रन सामान्य है और वह जाँच नहीं चलती. जो सोर्स कुछ रिकॉर्ड लौटाता है, लेकिन जितने चाहिए उससे कम, वह बिल्कुल नहीं पकड़ा जाता.

आपत्ति कुछ ऐसी होती है: “15 मिनट के शेड्यूल पर दस ख़ाली रन ढाई घंटे होते हैं. पहले पर ही अलर्ट क्यों नहीं?” कॉन्टैक्ट सिंक सच में डिफ़ॉल्ट रूप से हर 15 मिनट पर चलते हैं. और पंद्रह मिनट में किसी स्टोर पर कोई नया ग्राहक न आना आम बात है. पहले ख़ाली रन पर अलर्ट हर रात बजता, और जो अलर्ट हमेशा बजता है उसे कोई नहीं पढ़ता. वह सीमा रफ़्तार के बदले भरोसा चुनती है. फिर भी यह चुप्पी के बारे में एक अंदाज़ा है, लेखकों का नियम नहीं.

6. एक बार तय करें कि सिंक क्या लिख सकता है, और हर रन से यह साबित करवाएँ

उनका पाँचवाँ नियम एजेंट की प्राथमिकताओं को “ऐसे स्टोर में रखता है जिसे एजेंट एडिट नहीं कर सकता.” उनका छठा नियम एजेंट को जहाँ वह सिर्फ़ पढ़ता है वहाँ सिर्फ़-पढ़ने की एक्सेस देता है, और हर रन के ख़र्च की सीमा तय करता है. दोनों इसलिए हैं क्योंकि एजेंट दूसरों का लिखा टेक्स्ट पढ़ता है, और वह टेक्स्ट उसे आदेश देने की कोशिश कर सकता है.

सिंक के लिए प्राथमिकताओं वाली फ़ाइल का रूप है पब्लिश किया गया नियम. Tajo सिंक को पब्लिश करना उसे एक डाइजेस्ट से बाँध देता है, ठीक उसी नियम के जिसका प्रीव्यू किया गया था. उसे एडिट करना उसे ड्राफ़्ट में लौटा देता है, और दोबारा चलने से पहले वह फिर प्रीव्यू से गुज़रता है. हर रन, कुछ भी बदलने से पहले, जाँचता है कि वह वही पब्लिश किया गया वर्शन उन्हीं कनेक्शनों के साथ चला रहा है जिनके साथ वह पब्लिश हुआ था. जो रन यह जाँच फ़ेल करता है, वह रीट्राई नहीं होता. दिशा भी तय है: सिंक नियम एक ही दिशा में लिखता है और कभी वापस Shopify में नहीं.

ख़र्च की सीमा का कोई जोड़ नहीं है. हमारे सिंक रन पर हर रन की कोई ख़र्च सीमा नहीं है. रीट्राई सीमा और पॉज़ यह तय करते हैं कि फ़ेलियर कितनी देर चल सकता है, यह नहीं कि रन की लागत कितनी है.

क्या बना है, और क्या नहीं

बना हुआ, यह लिखे जाने तक:

• एक कर्सर जो सिर्फ़ उस बैच के बाद आगे बढ़ता है जिसमें हर रिकॉर्ड पहुँच गया हो, और शेड्यूल्ड ऑर्डर्स का एक कर्सर जिसे किसी व्यक्ति के शुरू किए रन पीछे नहीं कर सकते.
• हर रिकॉर्ड के लिए एक डिलीवरी कुंजी, जिसे सात दिन तक रखे जाने वाले पूरे हुए राइट्स के लेजर से जाँचा जाता है.
• हर सिंक के लिए एक लीज़, जिसे राइट से पहले और कर्सर आगे बढ़ने से पहले जाँचा जाता है.
• हर रन के लिए पाँच अटेम्प्ट, 60 सेकंड और फिर 120, 240 और 480 के इंतज़ार के साथ, टकराव या अवैध पब्लिकेशन पर कोई रीट्राई नहीं.
• लगातार पाँच रन फ़ेल होने पर पॉज़, जो सिंक के पेज पर दिखता है.
• हर घंटे का अलर्ट जब पिछले 24 घंटों में कोई रन सफल न हुआ हो.
• मार्केटिंग ऑडियंस में लिखे जाने वाले कॉन्टैक्ट्स के लिए रन टाइम पर सहमति फ़िल्टर, और हर रन पर यह जाँच कि वह पब्लिश किया गया वर्शन है.

नहीं बना, और इस पर भरोसा करने से पहले जानने लायक़:

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

जब इनमें से कुछ आपके अपने सिंक पर दिखे, तो अटके या फ़ेल हुए सिंक को बहाल करें बताता है कि आपको क्या दिखता है और क्या करना है.

लेखकों ने छह नियम एक ऐसे ब्रीफ़ के लिए लिखे जिसे कोई व्यक्ति हर सुबह पढ़ता है. सिंक का सुबह कोई पाठक होता ही नहीं, इसीलिए उसे इनकी और ज़्यादा ज़रूरत है. नियम एक से चार और नियम छह आज हमारे रनर में कोड हैं. नियम पाँच आधा लिखा है: जो सिंक अपना सोर्स नहीं पढ़ सकता, उसे यह बताना चाहिए.