निर्णय का आधार
सूचना आना व्यवसाय कार्रवाई पूरी होना नहीं। दोहराव और बदले क्रम के लिए डिजाइन करें। Stripe यह व्यवहार बताता है; दूसरे प्रदाता का अनुबंध अलग जाँचें।
एक व्यावहारिक उदाहरण
काल्पनिक “बिल भुगतान” घटना जाँचें, ID और काम टिकाऊ रूप में रखें, फिर स्वीकृति दें। दोहराव पहचानकर दूसरा क्रेडिट न करें। बाद की विफलता दोबारा चलने वाली स्थिति रखे।
विकल्पों का आकलन
Inbox आने वाली घटना और outbox अपनी transaction से निकला काम दर्ज करता है। वे स्थायी इरादा और नेटवर्क अलग करते हैं। मिलान बिना गलती सूचना भी अंतर खोजता है।
योजना कहाँ टूटती है
ID केवल प्रक्रिया की मेमोरी में न रखें और बदलाव commit होने से पहले पूरा न कहें। पुरानी घटना में राज्य या संस्करण नियम लें। अस्थायी गलती में अंतराल रखें, गलत डेटा समीक्षा में दें।
डिलिवरी पहचान और व्यवसाय पहचान अलग करें
इवेंट ID और बिल संदर्भ रखें। अलग घटनाएँ एक बिल से जुड़ सकती हैं; पहली बार के बाद सभी रोकना वैध बदलाव खोता है। उसी घटना की पुनरावृत्ति दूसरा क्रेडिट भी न बनाए। प्राप्ति कुंजी और व्यावसायिक स्थिति नियम तय कर जाँचों को वास्तविक बदलाव के साथ कमिट करें।
काम स्वीकारने से पहले प्रलेखित तरीके से भेजने वाला जाँचें। हस्ताक्षर मूल body पर हो तो JSON फिर बनाने के बजाय मिले bytes रखें। साइनिंग रहस्य लॉग या कोड में न रखें। सत्यापन, retry और रखने का समय प्रदाता के अनुबंध का भाग हैं; दूसरे की नकल गलत चीज जाँच सकती है।
मुश्किल समय पर बहाली साबित करें
वर्कर को प्राप्ति के बाद, स्थायी स्वीकृति के बाद और रिकॉर्ड बदलते समय रोकें। पुनः शुरू होने पर inbox और व्यवसाय रिकॉर्ड जाँचें। बाहरी असर स्थानीय नतीजा बचने से पहले स्वीकार हो सकता है। समर्थित idempotency या मिलान खोज उपयोग करें; स्थानीय स्थिति अकेले ठीक एक बार डिलिवरी की गारंटी नहीं।
नियंत्रित replay मूल पहचान और कारण रखे। स्थायी गलत डेटा अपवाद में जाए, अंतहीन प्रयास में नहीं। मिलान तय अवधि में आधिकारिक रिकॉर्ड तुलना करे। रिपोर्ट पढ़ने वाला, जरूरी अंतर का उपचार और बंद करने का प्रमाण तय करें। मालिक के बिना कतार डेटा बचा सकती है जबकि किसी को काम रुकने का पता न हो।
काम शुरू कराने से पहले
दोहराने पर एक असर है? worker दुर्घटना के बाद चलता है? एक रिकॉर्ड जाँचकर सुरक्षित दोहरा सकते हैं? एकीकरण स्वीकृति में ये प्रदर्शन रखें।