एक order flow payments, inventory और shipping तक फैला है, और हर एक का अपना डेटाबेस है। आप पूरी चीज़ को consistent कैसे रखेंगे?

आप एक ही distributed transaction का ख्याल छोड़ देते हैं और saga इस्तेमाल करते हैं: local transactions की एक श्रृंखला, जहां हर कदम एक event publish करता है जो अगला कदम चलाता है, और हर कदम के पास उसे उलटने के लिए एक compensating action होता है। consistency eventual हो जाती है, इसलिए असली डिज़ाइन काम यह तय करना है कि क्या compensate करना है, क्या retry करना है और क्या किसी इंसान तक पहुंचाना है। flow को साफ साफ मॉडल करें, या तो events के ज़रिए choreographed या किसी orchestrator से चलाया हुआ।

तीन services और तीन डेटाबेस पर two phase commit का मतलब है network के आर पार locks पकड़े रखना और एक coordinator जो मर जाए तो सब कुछ ठप कर सकता है, इसलिए मैं वह नहीं करूंगा। इसके बजाय flow एक saga बन जाता है। हर service अपना local transaction करती है और एक event भेजती है, और हर कदम की एक तय compensation होती है: अगर shipping allocate नहीं कर पाया, तो हम inventory reservation छोड़ देते हैं और payment refund या void कर देते हैं। अहम बात यह है कि compensation एक बिज़नेस कार्रवाई है, rollback नहीं; refund एक दिखने वाला रिकॉर्ड छोड़ता है और यही सही भी है। जिस भी चीज़ में तीन से ज़्यादा कदम हों, वहां मैं शुद्ध choreography की जगह orchestrator लेता हूं, क्योंकि choreography में असली flow कहीं लिखा नहीं होता और कोई नहीं बता पाता कि कोई order कहां अटका है। orchestrator मुझे एक state machine, हर कदम पर timeouts और query करने लायक status देता है। हर कदम idempotent है और backoff के साथ retry होता है, और जिसकी retries खत्म हो जाएं वह order id के साथ एक operations queue में चला जाता है, क्योंकि कुछ नाकामियों के लिए सचमुच इंसान चाहिए।