A szolgáltatások között általában a strong konzisztenciáról lemondasz az eventual konzisztencia javára, és a CQRS és az event sourcing alkalmazására támaszkodva teszed ezt gyakorlatiassá és helyessé.
Egy változás után a replikák "hamarosan" helyett azonnal konvergálnak. Elfogadható a legtöbb üzleti folyamatnál (egy készletszám egy másodpercet késhet), elfogadhatatlan azonban néhány esetben (egy bankszámla egyenlege).
Válaszd el az írási modellt egy vagy több olvasási modellből.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Az olvasások függetlenül skálázhatók és formálódhatnak az írásokhoz képest; az olvasási modellt az események frissítik, így eventual konzisztencia jellegű.
Tárolj az igazság forrásaként az események sorozatát, ne csak a jelenlegi állapotot. A jelenlegi állapot az események feldolgozásának egy rezultátuma.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technika | Előnyök | Költségek |
|---|---|---|
| Eventual consistency | Elérhetőség, méretezés | Elavult adatok, konfliktusok |
| CQRS | Olvasás/írás méretezés | Két modell szinkronizálása |
| Event sourcing | Audit, visszajátszás, előzmények | Schema/event evolúció, komplexitás |
Ne használj event sourcing-ot mindenhol — erőteljes, de nehéz. Alkalmazza csak ott, ahol az audit/előzmények valóban fontosak.
Az elosztott rendszerek nem lehetnek egyidejűleg strong konzisztensek, elérhetőek és partícióhoz toleránsak, így a senior szintű tervezés arról szól, hogy hol elfogadható az eventual consistency.
A CQRS és az event sourcing megadja neked az eszközöket ahhoz, hogy az eventual consistency megbízható és auditálható legyen — azonban mindkettő igazi komplexitást ad hozzá, ezért csak stratégikusan, nem alapértelmezésből alkalmazd őket.