Mezi službami obvykle obětujete silnou konzistenci za eventuální konzistenci a spoléháte se na CQRS a event sourcing, abyste to udělali praktickým a správným.
Po změně se repliky sbíhají "brzy" namísto okamžitě. Přijatelné pro většinu obchodních toků (počet inventáře se může zpozdit o sekundu), nepřijatelné pro některé (kontrola zůstatku na bankovním účtu).
Odděľte model zápisu od jednoho nebo více modelů čtení.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Čtení se škáluje a přeformátuje nezávisle na zápisech; model čtení se aktualizuje z událostí, takže je eventuálně konzistentní.
Ukládejte sekvenci událostí jako zdroj pravdy, nikoli jen aktuální stav. Aktuální stav je skládání přes události.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technika | Výhody | Náklady |
|---|---|---|
| Eventuální konzistence | Dostupnost, škálovatelnost | Zastaralé čtení, konflikty |
| CQRS | Škálování čtení/zápisu | Dva modely k udržování v synchronizaci |
| Event sourcing | Audit, přehrávka, historie | Evoluce schématu/události, složitost |
Ne všude zavádějte event sourcing — je to výkonné, ale těžké. Používejte jej tam, kde audit/historie opravdu záleží.
Distribuované systémy nemohou mít současně silnou konzistenci, dostupnost a toleranci k rozdělení, takže senior design je o tom, kde vybrat eventuální konzistenci jako přijatelnou.
CQRS a event sourcing vám dávají nástroje, aby byla eventuální konzistence spolehlivá a auditovatelná — ale každý přidává skutečnou složitost, takže je aplikujte chirurgicky, ne ve výchozím nastavení.