Bij services wissel je meestal sterke consistentie in voor uiteindelijke consistentie, en steun je op CQRS en event sourcing om dat praktisch en correct te maken.
Na een wijziging convergeren replica's "binnenkort" in plaats van onmiddellijk. Aanvaardbaar voor de meeste bedrijfsprocessen (een voorraadtelling kan een seconde achterlopen), onaanvaardbaar voor sommige (een banksaldocheck).
Scheidt het write model van één of meer read models.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Leesbewerkingen schalen en hervormen onafhankelijk van schrijfbewerkingen; het read model wordt bijgewerkt vanuit events, dus het is uiteindelijk consistent.
Sla de reeks events op als bron van waarheid, niet alleen de huidige status. Huidige status is een fold over events.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Techniek | Voordelen | Kosten |
|---|---|---|
| Uiteindelijke consistentie | Beschikbaarheid, schaal | Verouderde leesbewerkingen, conflicten |
| CQRS | Lees-/schrijfschaal | Twee modellen die gesynchroniseerd moeten blijven |
| Event sourcing | Audit, replay, geschiedenis | Schema/event-evolutie, complexiteit |
Pas event sourcing niet overal toe — het is krachtig maar zwaar. Gebruik het waar audit/geschiedenis werkelijk van belang is.
Gedistribueerde systemen kunnen niet tegelijkertijd sterke consistentie, beschikbaarheid en partitietolerantie hebben, dus senior design gaat over het kiezen waar uiteindelijke consistentie aanvaardbaar is.
CQRS en event sourcing geven je de tools om uiteindelijke consistentie betrouwbaar en controleerbaar te maken — maar elk voegt echte complexiteit toe, dus pas ze chirurgisch toe, niet standaard.