Paslaugų atžvilgiu paprastai keičiatės stiprų nuoseklumą už galutiną nuoseklumą ir pasitikitės CQRS ir event sourcing tuo praktiškai ir teisingai.
Po pasikeitimo replikacijos suartėja "netrukus" o ne iš karto. Priimtina daugumai verslo srautų (atsargų skaičius gali atsilikti per sekundę), nepriimtina kai kuriems (banko balanso patikra).
Atskirkite rašymo modelį nuo vieno ar kelių skaitymo modelių.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Skaitymai keičia mastą ir peršamo nepriklausomai nuo rašymų; skaitymo modelis atnaujinamas iš įvykių, todėl jis yra galutinai nuoseklus.
Saugokite įvykių seką kaip tiesos šaltinį, o ne tik dabartinę būseną. Dabartinė būsena yra sulankyta įvykiams.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technika | Prieiga | Kaina |
|---|---|---|
| Galutinis nuoseklumas | Pasiekiamumas, mastelis | Pasenę skaitymai, konfliktai |
| CQRS | Skaitymo/rašymo mastelis | Du modeliai, kuriuos reikia sinchronizuoti |
| Event sourcing | Auditas, kartoti, istorija | Schemos/įvykio evoliucija, sudėtingumas |
Nepriiminėkite event sourcing visur — tai galioti, bet sunkus. Naudokite jį ten, kur auditas/istorija tikrai svarbi.
Paskirstytos sistemos negali vienu metu turėti stipraus nuoseklumo, pasiekiamumo ir dalies tolerancijos, todėl vyresnioji projekta susideda iš to, kur galutinis nuoseklumas yra priimtinas.
CQRS ir event sourcing suteikia jums priemones galutiniu nuoseklumu pasinaudoti patikimai ir audituoti — tačiau kiekvienas prideda tikrą sudėtingumą, todėl taikykite juos chirurgiškai, o ne pagal nutylėjimą.