W architekturze rozproszonej zwykle handlujesz silną spójnością za ostatecznie spójną, i opierasz się na CQRS i event sourcing, aby to praktyczne i poprawne.
Po zmianach, repliki zbiegają się "wkrótce" zamiast natychmiast. Akceptowalne dla większości procesów biznesowych (liczba inwentarza może się opóźniać o sekundę), nieakceptowalne dla niektórych (sprawdzenie salda konta bankowego).
Oddziel model zapisu od jednego lub więcej modeli odczytu.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Odczyty skalują się i przekształcają niezależnie od zapisów; model odczytu jest aktualizowany ze zdarzeń, więc jest ostatecznie spójny.
Zachowuj sekwencję zdarzeń jako źródło prawdy, a nie tylko stan bieżący. Stan bieżący jest zwijanym wynikiem zdarzeń.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technika | Korzyści | Koszty |
|---|---|---|
| Eventual consistency | Dostępność, skala | Nieświeże odczyty, konflikty |
| CQRS | Skala odczytu/zapisu | Dwa modele do synchronizacji |
| Event sourcing | Audyt, odtwarzanie, historia | Ewolucja schematu/zdarzeń, złożoność |
Nie wdrażaj event sourcing wszędzie — to potężne, ale ciężkie. Używaj go tam, gdzie audyt/historia naprawdę ma znaczenie.
Systemy rozproszone nie mogą mieć silnej spójności, dostępności i tolerancji na partycje jednocześnie, więc dojrzałe projektowanie polega na wyborze, gdzie eventual consistency jest akceptowalna.
CQRS i event sourcing dają ci narzędzia, aby uczynić eventual consistency niezawodnym i możliwym do audytu — ale każde dodaje rzeczywistą złożoność, więc stosuj je chirurgicznie, a nie domyślnie.