சேவைகள் முழுவதும் நீங்கள் பொதுவாக strong consistency ஐ eventual consistency க்கு மாற்றி, CQRS மற்றும் event sourcing ஐ பயன்படுத்தி அதை நடைமுறையில் சரியாக செய்ய வேண்டும்.
ஒரு மாற்றத்திற்குப் பிறகு, replicas உடனடியாக இல்லாமல் "விரைவில்" convergence ஆகின்றன. பெரும்பாலான business workflows க்கு acceptable ஆகும் (ஒரு inventory count ஐ ஒரு நொடி delay ஆக இருக்கலாம்), சில விஷயங்களுக்கு unacceptable ஆகும் (ஒரு bank balance check).
write model ஐ ஒன்று அல்லது அதற்கு மேல் read models இலிருந்து பிரிக்கவும்.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Reads scale மற்றும் reshape writes இலிருந்து independent ஆக நடக்கின்றன; read model events இலிருந்து update ஆகும், எனவே இது eventually consistent ஆகும்.
events இன் sequence ஐ source of truth ஆக store செய்யவும், உதாரணமாக current state மட்டுமல்ல. Current state ஆனது events மீது ஒரு fold ஆகும்.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technique | Gains | Costs |
|---|---|---|
| Eventual consistency | Availability, scale | Stale reads, conflicts |
| CQRS | Read/write scale | Two models to keep in sync |
| Event sourcing | Audit, replay, history | Schema/event evolution, complexity |
Event sourcing ஐ எங்கும் adopt செய்யாதீர்கள் — இது powerful ஆனால் heavy ஆகும். Audit/history உண்மையாக முக்கியமாக இருக்கும் இடங்களில் பயன்படுத்தவும்.
Distributed systems ஆனது strong consistency, availability, மற்றும் partition tolerance ஆகிய மூன்றையும் ஒரே நேரத்தில் கொண்டிருக்க முடியாது, எனவே senior design ஆனது eventual consistency ஐ எங்கே acceptable ஆக இருக்கும் என்பதை தேர்ந்தெடுக்கும் பற்றி உள்ளது.
CQRS மற்றும் event sourcing ஆனது eventual consistency ஐ reliable மற்றும் auditable ஆக செய்ய உங்களுக்கு tools ஐ கொடுக்கின்றன — ஆனால் ஒவ்வொன்றும் real complexity ஐ சேர்க்கின்றன, எனவே அவற்றை surgically பயன்படுத்தவும், default ஆக பயன்படுத்தாதீர்கள்.