På tværs af tjenester handler du typisk stærk konsistens for eventuel konsistens og er afhængig af CQRS og event sourcing for at gøre det praktisk og korrekt.
Efter en ændring konvergerer replikaer "snart" i stedet for øjeblikkeligt. Acceptabelt for de fleste forretningsflows (en lageroptellingCount kan forsinkes et sekund), uacceptabelt for nogle (en bankbalancekontrol).
Adskil skrivemodellen fra en eller flere læsemodeller.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Læsninger skaleres og omformes uafhængigt af skrivninger; læsemodellen opdateres fra begivenheder, så den er til sidst konsistent.
Lagre sekvensen af begivenheder som sandheden, ikke blot den aktuelle tilstand. Nuværende tilstand er en fold over begivenheder.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Teknik | Gevinster | Omkostninger |
|---|---|---|
| Eventuel konsistens | Tilgængelighed, skala | Forladte læsninger, konflikter |
| CQRS | Læse-/skriveskala | To modeller at holde synkroniseret |
| Event sourcing | Revision, afspilning, historie | Skema-/begivenheds evolution, kompleksitet |
Adopter ikke event sourcing overalt — det er kraftfuldt men tungt. Brug det hvor revision/historie virkelig betyder noget.
Distribuerede systemer kan ikke have stærk konsistens, tilgængelighed og partitionstolerance på samme tid, så senior design handler om at vælge hvor eventuel konsistens er acceptabel.
CQRS og event sourcing giver dig værktøjerne til at gøre eventuel konsistens pålidelig og revisionsspor — men hver tilføjer rigtig kompleksitet, så anvend dem kirurgisk, ikke som standard.