सेवांमध्ये तुम्ही सामान्यतः मजबूत सुसंगतता अंतिम सुसंगतताचे व्यापार करता, आणि 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)
| तंत्र | लाभ | खर्च |
|---|---|---|
| अंतिम सुसंगतता | उपलब्धता, स्केल | स्टेल वाचन, संघर्ष |
| CQRS | वाचन/लेखन स्केल | दोन मॉडेल सिंक्रोनाइজ ठेवायचे |
| Event sourcing | ऑडिट, पुनरावृत्ती, इतिहास | स्कीमा/इव्हेंट विकास, जटिलता |
सर्वत्र event sourcing स्वीकार करू नका — हे शक्तिशाली आहे परंतु जड. जिथे ऑडिट/इतिहास खरोखर महत्वाचे आहे तिथे त्याचा वापर करा.
वितरित प्रणाली एकाच वेळी मजबूत सुसंगतता, उपलब्धता आणि विभाजन सहिष्णुता असू शकत नाहीत, म्हणून सीनियर डिজाइन अंतिम सुसंगतता कुठे स्वीकार्य आहे हे निवडण्याबद्दल आहे.
CQRS आणि event sourcing तुम्हाला अंतिम सुसंगतता विश्वसनीय आणि ऑडिट करण्यायोग्य बनवण्याचे साधन देतात — परंतु प्रत्येक खरी जटिलता जोडते, म्हणून त्यांचा सर्जनशील पद्धतीने लागू करा, डीफॉल्टरूप नाही.