Tra servizi, in genere si scambia la consistenza forte per una consistenza eventuale, e ci si affida a CQRS e event sourcing per renderlo pratico e corretto.
Dopo una modifica, le repliche convergono "presto" piuttosto che istantaneamente. Accettabile per la maggior parte dei flussi di business (un conteggio dell'inventario può ritardare di un secondo), inaccettabile per altri (un controllo del saldo bancario).
Separare il write model da uno o più read models.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Le letture si scalano e si rimodellano indipendentemente dalle scritture; il read model viene aggiornato dagli eventi, quindi è eventualmente consistente.
Archiviare la sequenza di eventi come fonte di verità, non solo lo stato attuale. Lo stato attuale è un fold su gli eventi.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Tecnica | Vantaggi | Costi |
|---|---|---|
| Eventual consistency | Disponibilità, scalabilità | Letture non aggiornate, conflitti |
| CQRS | Scalabilità letture/scritture | Due modelli da mantenere in sincronia |
| Event sourcing | Audit, replay, storia | Evoluzione schema/evento, complessità |
Non adottare event sourcing ovunque — è potente ma pesante. Usalo dove l'audit/storia conta veramente.
I sistemi distribuiti non possono avere contemporaneamente consistenza forte, disponibilità e tolleranza ai partizionamenti, quindi il design senior riguarda la scelta di dove la eventual consistency è accettabile.
CQRS e event sourcing ti danno gli strumenti per rendere la eventual consistency affidabile e verificabile — ma ognuno aggiunge reale complessità, quindi applicali chirurgicamente, non per default.