Între servicii, de obicei sacrifici consistența puternică pentru consistența finală, și te bazezi pe CQRS și event sourcing pentru a face asta practic și corect.
După o schimbare, replicile converg "în curând" mai degrabă decât instantaneu. Acceptabil pentru majoritatea fluxurilor de afaceri (un inventar poate întârzia o secundă), inacceptabil pentru unele (o verificare a soldului unui cont bancar).
Separează modelul de scriere de unul sau mai multe modele de citire.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Citirile se scalează și se reformatează independent de scrieri; modelul de citire este actualizat din evenimente, deci este eventual consistent.
Stochează secvența de evenimente ca sursă de adevăr, nu doar starea curentă. Starea curentă este rezultatul aplicării unor funcții peste evenimente.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Tehnică | Beneficii | Costuri |
|---|---|---|
| Eventual consistency | Disponibilitate, scalabilitate | Citiri vechi, conflicte |
| CQRS | Scalare citire/scriere | Două modele de menținut în sincron |
| Event sourcing | Audit, replay, istoric | Evoluția schemei/evenimentelor, complexitate |
Nu adopta event sourcing peste tot — este puternic dar greu. Folosește-l unde audit/istoric contează cu adevărat.
Sistemele distribuite nu pot avea consistență puternică, disponibilitate și toleranță la partiționare toate deodată, deci designul senior este despre alegerea unde consistența finală este acceptabilă.
CQRS și event sourcing îți dau instrumentele pentru a face consistența finală fiabilă și auditabilă — dar fiecare adaugă complexitate reală, deci aplică-le cu precizie, nu implicit.