सेवाहरू भरि तपाई सामान्यतः strong स्थिरतालाई eventual स्थिरताको लागि बदलेर CQRS र event sourcing मा निर्भर गर्नुहुन्छ यो व्यावहारिक र सही बनाउन।
परिवर्तन गरेपछि, प्रतिलिपिहरू तुरुन्त नभई "छिट्टै" एकसाथ आउँछन्। अधिकांश व्यावसायिक प्रवाहको लागि स्वीकार्य (एक इन्भेन्टरी गणना एक सेकेन्ड पछाडि हुन सक्छ), केहीको लागि अस्वीकार्य (एक बैंक ब्यालेन्स जाँच)।
write model लाई एक वा अधिक read models बाट अलग गर्नुहोस्।
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
पढनहरू लेखनहरूबाट स्वतन्त्ररूपमा मापन र पुनर्गठन गर्छन्; read model घटनाहरूबाट अपडेट गरिन्छ, त्यसैले यो अन्तिम स्थिरतामा छ।
घटनाहरूको क्रम लाई स्रोत सत्यको रूपमा संग्रहण गर्नुहोस्, केवल वर्तमान स्थिति होइन। वर्तमान स्थिति घटनाहरूको फोल्ड हो।
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technique | लाभहरू | खर्चहरू |
|---|---|---|
| अन्तिम स्थिरता | उपलब्धता, मापन | अप्रचलित पठनहरू, द्वन्द्वहरू |
| CQRS | पढन/लेखन मापन | दुई मडेलहरू सिंक मा राख्नु |
| घटना sourcing | अडिट, replay, इतिहास | Schema/event विकास, जटिलता |
घटना sourcing सर्वत्र अपनाउनु नहोस् — यो शक्तिशाली तर भारी छ। यो प्रयोग गर्नुहोस् जहाँ अडिट/इतिहास साँच्चै महत्त्वपूर्ण छ।
वितरित प्रणालीहरूले एकै साथ strong स्थिरता, उपलब्धता, र partition सहन्शीलता सबै रख्न सक्दैनन्, त्यसैले वरिष्ठ डिजाइन भनेको अन्तिम स्थिरता कहाँ स्वीकार्य छ भनेर छनौट गर्नु हो।
CQRS र event sourcing ले तपाईलाई अन्तिम स्थिरतालाई विश्वसनीय र अडिट गर्न योग्य बनाउन सरजनाहरू दिन्छ — तर प्रत्येकले वास्तविक जटिलता थप्छ, त्यसैले उनीहरूलाई सर्जिकली लागू गर्नुहोस्, पूर्वनिर्धारण गरेर होइन।