Katika huduma nyingi kwa kawaida hubadilisha strong consistency na eventual consistency, na kutegemea CQRS na event sourcing ili kufanya hilo kuwa rafiki na sahihi.
Baada ya mabadiliko, nakala zinabadilishana "haraka" kuliko haraka. Inapokelewa kwa akila mikakati ya biashara (hesabu ya hifadhi inaweza kupokelewa kwa sekunde), haikubaliwi kwa baadhi (kuangalia salio la benki).
Tenga write model kutoka kwa moja au zaidi read models.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
Kusoma kunapanuka na kubadilisha kujitegemea kwa maandishi; read model inabadilishwa kutokana na matukio, kwa hiyo ni eventually consistent.
Hifadhi mlolongo wa matukio kama chanzo cha kweli, si tu hali ya sasa. Hali ya sasa ni kupiga kumwa kwa matukio.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| Technique | Gains | Costs |
|---|---|---|
| Eventual consistency | Availability, scale | Stale reads, conflicts |
| CQRS | Read/write scale | Two models to keep in sync |
| Event sourcing | Audit, replay, history | Schema/event evolution, complexity |
Usihitaji event sourcing kila mahali — ni kizuri lakini uzito. Itumia ambapo audit/history kweli maada.
Mifumo iliyogawanywa haiwezi kuwa na consistency ya nguvu, availability, na partition tolerance kwa wakati mmoja, kwa hiyo muundo wa juu ni kuhusu kuchagua mahali eventual consistency inapokelewa.
CQRS na event sourcing hukupa zana za kufanya eventual consistency kuwa na kutegemeka na kusikitishwa — lakini kila mmoja huongeza utata halisi, kwa hiyo zitumie kwa kirurgija, si kwa chaguo la zamani.