På tvers av tjenester bytter du vanligvis sterk konsistens mot eventual konsistens, og støtter deg på CQRS og event sourcing for å gjøre det praktisk og korrekt.
Etter en endring konvergerer replikaer "snart" i stedet for umiddelbart. Akseptabelt for de fleste forretningsprosesser (en lagertelling kan ligge et sekund etter), uakseptabelt for noen (en bankkontrollsjekk).
Separér write model fra en eller flere read models.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Leser skalerer og omformes uavhengig av skrivinger; read model oppdateres fra events, så det er eventually consistent.
Lagre sekvensen av events som kilden til sannhet, ikke bare gjeldende tilstand. Gjeldende tilstand er en fold over events.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Teknikk | Gevinster | Kostnader |
|---|---|---|
| Eventual consistency | Tilgjengelighet, skalering | Foreldede lesinger, konflikter |
| CQRS | Les/skriv skalering | To modeller å holde i synk |
| Event sourcing | Revisjon, replay, historie | Skjema-/event-evolusjon, kompleksitet |
Ikke adopter event sourcing overalt — det er kraftig men tungt. Bruk det der revisjon/historie virkelig betyr noe.
Distribuerte systemer kan ikke ha sterk konsistens, tilgjengelighet og partisjontoleranse på en gang, så seniordesign handler om å velge hvor eventual consistency er akseptabelt.
CQRS og event sourcing gir deg verktøyene til å gjøre eventual consistency pålitelig og revisorbar — men hver teknikk legger til reell kompleksitet, så bruk dem kirurgisk, ikke som standard.