# वितरित ट्रांज़ैक्शन और सागा — सिस्टम डिज़ाइन

Source: https://www.geekswithgeeks.com/hi/system-design/sd-distributed-transactions

> एक साझा डेटाबेस के बिना सेवाओं में डेटा को सही रखना।

## यह कठिन क्यों है

एकल-डेटाबेस ट्रांज़ैक्शन मुफ़्त में एटॉमिक होता है। एक बार डेटा अलग-अलग डेटाबेस वाली अलग-अलग सेवाओं में रहने लगे, तो बहु-चरण ऑपरेशन को समग्र रूप से सफल या विफल बनाने के लिए स्पष्ट प्रोटोकॉल चाहिए।

## टू-फ़ेज़ कमिट

**2PC** में एक कोऑर्डिनेटर हर भागीदार से **prepare** करने को कहता है (लॉक करें और कमिट का वादा करें), फिर, केवल यदि सभी हाँ कहें, सबको **commit** करने को कहता है। यह मज़बूत कंसिस्टेंसी देता है पर कोऑर्डिनेटर बीच में मरे तो अटक जाता है — बड़े स्केल, उच्च-उपलब्धता सिस्टम के लिए कमज़ोर फ़िट।

## सागा पैटर्न

एक **सागा** ट्रांज़ैक्शन को स्थानीय ट्रांज़ैक्शन की एक श्रृंखला में तोड़ता है, हर एक के साथ इसे पूर्ववत करने के लिए एक **प्रतिपूरक क्रिया**। यदि 5 में से चरण 4 विफल हो, तो आप चरण 3, 2, 1 के लिए प्रतिपूरण चलाते हैं — सेवाओं में कोई लॉक नहीं रहता, पर आप eventual consistency के लिए डिज़ाइन करते हैं।

## स्केल पर सागा को प्राथमिकता दें

अधिकांश बड़े सिस्टम (ई-कॉमर्स चेकआउट, यात्रा बुकिंग) वर्कफ़्लो इंजन द्वारा ऑर्केस्ट्रेटेड या इवेंट के ज़रिए समन्वित सागा उपयोग करते हैं, 2PC को संकीर्ण, कम-लेटेंसी दायरों जैसे एकल डेटाबेस क्लस्टर के लिए सुरक्षित रखते हैं।