సేవలుల్లో మీరు సాధారణంగా బలమైన సమంజస్యతను తుది సమంజస్యతకు బదిలీ చేస్తారు, మరియు CQRS మరియు ఈవెంట్ సోర్సింగ్ను ఆచరణీయం మరియు సరైనదిగా చేయడానికి ఆధారపడతారు.
మార్పు తర్వాత, ప్రతిరూపాలు "త్వరలో" కలుస్తాయి, కాని తక్షణమైనవి కాదు. ఎక్కువ వ్యాపారిక ప్రవాహాల కోసం ఆమోదయోగ్యం (ఇన్వెంటరీ గణన సెకను విలంబం కావచ్చు), కానీ కొన్నింటికి ఆమోదయోగ్యం కాదు (బ్యాంక్ బ్యాలెన్స్ చెక్).
రైట్ మోడల్ను ఒకటి లేదా అంతకంటే ఎక్కువ రీడ్ మోడల్ల నుండి వేరు చేయండి.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
రీడ్లు స్కేల్ చేయబడతాయి మరియు రైట్ల నుండి స్వతంత్రంగా రీశేప్ చేయబడతాయి; రీడ్ మోడల్ ఈవెంట్ల నుండి అప్డేట్ చేయబడుతుంది, కాబట్టి ఇది తుది సమంజస్యం.
ఈవెంట్ల క్రమాన్ని సంప్రతి స్థితి కంటే సత్యం యొక్క మూలంగా నిల్వ చేయండి. సంప్రతి స్థితి ఈవెంట్ల కంపైల్.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| టెక్నిక్ | లాభాలు | ఖర్చులు |
|---|---|---|
| తుది సమంజస్యత | లభ్యత, స్కేల్ | స్టేల్ రీడ్లు, సంఘర్షణలు |
| CQRS | రీడ్/రైట్ స్కేల్ | రెండు మోడల్లను సమకాలీకరణలో ఉంచుకోవాలి |
| ఈవెంట్ సోర్సింగ్ | ఆడిట్, రీప్లే, చరిత్ర | స్కీమా/ఈవెంట్ పరిణామం, సంక్లిష్టత |
ఈవెంట్ సోర్సింగ్ను ప్రతిచోటా నిర్దేశించవద్దు — ఇది శక్తిశాలీ కానీ భారీ. ఆడిట్/చరిత్ర నిజమైన ప్రాముఖ్యతను కలిగి ఉన్న చోట దీనిని ఉపయోగించండి.
విതరణ చేయబడిన సిస్టమ్లు బలమైన సమంజస్యత, లభ్యత, మరియు విభజన సహనశీలత అన్నింటిని ఒకేసారి కలిగి ఉండకపోవచ్చు, కాబట్టి సీనియర్ డిజైన్ తుది సమంజస్యత ఆమోదయోగ్యమైన చోటను ఎంచుకోవడం గురించి ఉంటుంది.
CQRS మరియు ఈవెంట్ సోర్సింగ్ మీకు తుది సమంజస్యతను నమ్మకమైనమైనదిగా మరియు ఆడిట్చేయదగినదిగా చేయడానికి సాధనాలను ఇస్తాయి — కానీ ప్రతిటి నిజమైన సంక్లిష్టతను జోడిస్తుంది, కాబట్టి వాటిని శస్త్రచిකిత్సలో వర్తింపజేయండి, డిఫాల్ట్ ద్వారా కాదు.