Über Services hinweg tauschen Sie üblicherweise starke Konsistenz gegen eventuelle Konsistenz ein und verlassen sich auf CQRS und Event Sourcing, um das praktisch und korrekt zu gestalten.
Nach einer Änderung konvergieren Replikas "bald" statt sofort. Akzeptabel für die meisten Geschäftsabläufe (ein Bestandszahl kann um eine Sekunde verzögert sein), inakzeptabel für einige (eine Bankkontostandsprüfung).
Trennen Sie das Schreibmodell von einem oder mehreren Lesemodellen.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Lesevorgänge skalieren und werden unabhängig von Schreibvorgängen umgestaltet; das Lesemodell wird aus Ereignissen aktualisiert und ist daher schließlich konsistent.
Speichern Sie die Abfolge von Ereignissen als Quelle der Wahrheit, nicht nur den aktuellen Zustand. Der aktuelle Zustand ist ein Fold über Ereignisse.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technik | Gewinne | Kosten |
|---|---|---|
| Eventual Consistency | Verfügbarkeit, Skalierbarkeit | Veraltete Lesevorgänge, Konflikte |
| CQRS | Lese-/Schreibskalierung | Zwei Modelle zum Synchronisieren |
| Event Sourcing | Audit, Wiederholung, Verlauf | Schema-/Ereignisentwicklung, Komplexität |
Adoptieren Sie Event Sourcing nicht überall — es ist leistungsstark, aber schwer. Verwenden Sie es dort, wo Audit/Verlauf wirklich wichtig ist.
Verteilte Systeme können nicht gleichzeitig starke Konsistenz, Verfügbarkeit und Partitionstoleranz haben, daher geht es bei Senior Design darum, zu wählen, wo eventuelle Konsistenz akzeptabel ist.
CQRS und Event Sourcing geben Ihnen die Werkzeuge, um eventuelle Konsistenz zuverlässig und überwachbar zu machen — aber jedes fügt echte Komplexität hinzu, also wenden Sie diese gezielt an, nicht standardmäßig.