Med storitvami običajno zamenjuješ močno konsistentnost za eventualno konsistentnost in se opiraš na CQRS ter event sourcing, da bi to naredil praktično in pravilno.
Po spremembi se replike "kmalu" usklajujejo namesto trenutno. Sprejemljivo za večino poslovnih tokov (zaloga se lahko zaostane sekundo), nesprejemljivo za nekatere (preverjanje stanja bančnega računa).
Loči write model od enega ali več read modelov.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Brani se skalirajo in preoblikujejo neodvisno od pisanj; read model se posodablja iz dogodkov, zato je eventualno konsistenten.
Shrani zaporedje dogodkov kot vir resnice, ne le trenutnega stanja. Trenutno stanje je rezultat preslikave preko dogodkov.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Tehnika | Dobički | Stroški |
|---|---|---|
| Eventualna konsistentnost | Dostopnost, skalabilnost | Zastareli odgovori, konflikti |
| CQRS | Skaliranje branja/pisanja | Dva modela za sinhronizacijo |
| Event sourcing | Revizija, ponovitev, zgodovina | Evolucija sheme/dogodkov, kompleksnost |
Ne prevzemi event sourcinga povsod — je močan, vendar zahteven. Uporabi ga tam, kjer je revizija/zgodovina res pomembna.
Porazdeljeni sistemi ne morejo imeti hkrati močne konsistentnosti, dostopnosti in tolerantnosti na razdelitev, zato je vrhunski dizajn stvar izbire, kje je eventualna konsistentnost sprejemljiva.
CQRS in event sourcing ti dajeta orodja, da eventualno konsistentnost naredita zanesljivo in revidirano — vendar vsak dodaja pravo kompleksnost, zato ju uporabi premišljeno, ne privzeto.