Në të gjitha shërbimet zakonisht ju këmbeni konsistencën e fortë me konsistencën përfundimtare, dhe mbështeteni në CQRS dhe event sourcing për ta bërë atë praktike dhe të saktë.
Pas një ndryshimi, replikat konvergojnë "shpejt" sesa menjëherë. E pranueshme për shumicën e proceseve të biznesit (një numërimi i inventarit mund të vonojë një sekondë), e papranueshme për disa (një kontroll bilanci bankar).
Ndani modelin e shkrimit nga një ose më shumë modele leximi.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Leximet shkallëzohen dhe reshape përsëri në mënyrë të pavarur nga shkrimet; modeli i leximit përditësohet nga ngjarjet, kështu që ai është përfundimisht konsistent.
Ruani sekuencën e ngjarjeve si burim të vërtetë, jo vetëm gjendjen aktuale. Gjendja aktuale është një fold mbi ngjarjet.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Teknika | Fitim | Kosto |
|---|---|---|
| Eventual consistency | Disponibilitet, shkallë | Lexime të vjetra, konflikte |
| CQRS | Shkallë leximi/shkrimi | Dy modele për të mbajtur në sinkronizim |
| Event sourcing | Audit, replay, historik | Evolucioni i skemës/ngjarjeve, kompleksitet |
Mos adoptoni event sourcing kudo — është i fuqishëm por i rëndë. Përdoreni atje ku auditi/historiku vërtet ka rëndësi.
Sistemet e shpërndarë nuk mund të kenë konsistencë të fortë, disponibilitet dhe tolerancë ndaj ndarjeve të njëkohshme, kështu që dizajni i nivelit të lartë është rreth zgjedhjes se ku konsistenca përfundimtare është e pranueshme.
CQRS dhe event sourcing ju japin mjetet për ta bërë eventual consistency të besueshme dhe të audituar — por secila shton kompleksitet të vërtetë, kështu që zbatojini ato me kujdes, jo si standard.