सर्विसेज़ के बीच आप आमतौर पर स्ट्रॉन्ग कंसिस्टेंसी को eventual कंसिस्टेंसी के बदले छोड़ देते हैं, और उसे व्यावहारिक और सही बनाने के लिए CQRS और event sourcing पर निर्भर रहते हैं।
एक बदलाव के बाद, रेप्लिकाज़ "जल्द ही" अभिसरित होते हैं, तुरंत नहीं। अधिकांश व्यावसायिक फ़्लो के लिए स्वीकार्य (इन्वेंटरी काउंट एक सेकंड पीछे रह सकता है), कुछ के लिए अस्वीकार्य (बैंक बैलेंस चेक)।
राइट मॉडल को एक या अधिक रीड मॉडल्स से अलग करें।
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
रीड्स राइट्स से स्वतंत्र रूप से स्केल और रीशेप होते हैं; रीड मॉडल इवेंट्स से अपडेट होता है, इसलिए यह eventually consistent होता है।
सत्य के स्रोत के रूप में सिर्फ़ वर्तमान स्थिति नहीं, बल्कि इवेंट्स का अनुक्रम स्टोर करें। वर्तमान स्थिति इवेंट्स पर एक फ़ोल्ड होती है।
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| तकनीक | लाभ | लागत |
|---|---|---|
| Eventual consistency | उपलब्धता, स्केल | स्टेल रीड्स, कॉन्फ़्लिक्ट्स |
| CQRS | रीड/राइट स्केल | सिंक में रखने के लिए दो मॉडल |
| Event sourcing | ऑडिट, रीप्ले, हिस्ट्री | स्कीमा/इवेंट इवोल्यूशन, जटिलता |
event sourcing को हर जगह न अपनाएँ — यह शक्तिशाली है लेकिन भारी है। इसका उपयोग वहाँ करें जहाँ ऑडिट/हिस्ट्री वास्तव में मायने रखती है।
डिस्ट्रिब्यूटेड सिस्टम एक साथ स्ट्रॉन्ग कंसिस्टेंसी, उपलब्धता, और पार्टीशन टॉलरेंस तीनों नहीं रख सकते, इसलिए सीनियर डिज़ाइन इस बारे में है कि eventual consistency कहाँ स्वीकार्य है यह चुनना।
CQRS और event sourcing आपको eventual consistency को विश्वसनीय और ऑडिटेबल बनाने के टूल देते हैं — लेकिन प्रत्येक वास्तविक जटिलता जोड़ता है, इसलिए इन्हें डिफ़ॉल्ट रूप से नहीं, बल्कि सटीक रूप से लागू करें।