Između servisa obično mijenjate jaku konzistentnost za eventual konzistentnost, i oslanjate se na CQRS i event sourcing kako biste to učinili praktičnim i ispravnim.
Nakon promjene, replike konvergiraju "uskoro" umjesto trenutno. Prihvatljivo za većinu poslovnih tokova (broj inventara može zaostati sekundu ili dvije), neprihvatljivo za neke (provjera salda na bankovnom računu).
Odvojite model upisa od jednog ili više modela čitanja.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Čitanja se skaliraju i oblikuju neovisno o upisima; model čitanja se ažurira iz događaja, pa je stoga eventualno konzistentan.
Spremi redoslijed događaja kao izvor istine, ne samo trenutno stanje. Trenutno stanje je fold preko događaja.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Tehnika | Dobitci | Troškovi |
|---|---|---|
| Eventual consistency | Dostupnost, skalabilnost | Zastarjela čitanja, konflikti |
| CQRS | Skalabilnost čitanja/upisa | Dva modela koja trebaju biti usklađena |
| Event sourcing | Revizija, ponovni odabir, povijest | Evolucija sheme/događaja, složenost |
Ne primjenjujte event sourcing svugdje — moćan je ali težak. Koristite ga gdje je revizija/povijest doista važna.
Distribuirani sustavi ne mogu imati jaku konzistentnost, dostupnost i toleranciju particija sve odjednom, pa je dizajn senior razine o tome gdje je eventual consistency prihvatljiva.
CQRS i event sourcing daju vam alate da učinite eventual consistency pouzdanom i provjerivom — ali svaki dodaje pravu složenost, pa ih primijenite kirurški, ne kao zadanu postavku.