Palveluiden välillä yleensä vaihdat vahvan johdonmukaisuuden lopulta johdonmukaisuuteen ja luotat CQRS:ään ja event sourcingia tekemään sen käytännölliseksi ja oikeaksi.
Muutoksen jälkeen replikat lähentyvät "pian" välittömän sijaan. Hyväksyttävää useimmissa liiketoimintavirroissa (varaston määrä voi viivästyä sekunnin), hyväksyttävää joissain (pankkitilin saldon tarkistus).
Eroita kirjoitusmalli yhdestä tai useammasta luettavamallista.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Luvut skaalautuvat ja muotoillaan uudelleen itsenäisesti kirjoituksista; luettavamalli päivitetään tapahtumista, joten se on lopulta johdonmukainen.
Tallenna tapahtumasarja totuuden lähteenä, ei vain nykyinen tila. Nykyinen tila on taittaminen tapahtumille.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Tekniikka | Voitot | Kustannukset |
|---|---|---|
| Lopulta johdonmukaisuus | Saatavuus, skaalautuvuus | Vanhat luennot, ristiriidat |
| CQRS | Luku-/kirjoitus skaalautuvuus | Kaksi mallia synkronoitavaksi |
| Event sourcing | Tarkastus, toisto, historia | Kaavan/tapahtuman kehitys, monimutkaisuus |
Älä hyväksy event sourcingia kaikkialla — se on tehokas mutta raskas. Käytä sitä, missä tarkastus/historia todella merkitsee.
Jaetut järjestelmät eivät voi samanaikaisesti saada vahvaa johdonmukaisuutta, saatavuutta ja osiointinsietoa, joten senior-suunnittelu on siitä, mihin valita lopulta johdonmukaisuus hyväksyttäväksi.
CQRS ja event sourcing antavat sinulle työkalut tehdä lopulta johdonmukaisuudesta luotettavaa ja auditoitavaa — mutta jokainen lisää todellista monimutkaisuutta, joten käytä niitä kirurgisesti, ei oletuksena.