સેવાઓ જુદી જુદી વચ્ચે તમે સામાન્યતઃ મજબૂત સુસંગતાનો ઇવેંચુઅલ સુસંગતા માટે વેપાર કરો છો, અને તેને વ્યવહારુ અને સાચું બનાવવા માટે CQRS અને ઇવેંટ સોર્સિંગ પર આધાર રાખો છો।
ફેરફાર પછી, પ્રતિકૃતિઓ તાત્ક્ષણિક નહીં પણ "શીઘ્રે" એક બીજા તરફ વલણ કરે છે. મોટાભાગના વ્યવસાય પ્રવાહ માટે સ્વીકાર્ય છે (ઇનવેન્ટરી સંખ્યા એક સેકન્ડ લેગ કરી શકે છે), કેટલાક માટે અસ્વીકાર્ય છે (બેંક બેલેન્સ ચેક).
લેખન મોડેલ એક અથવા વધુ વાંચન મોડેલ કાંતરણ કરો.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
વાંચન સ્કેલ અને લેખનથી સ્વતંત્ર રીતે પુનર્નિર્માણ કરે છે; વાંચન મોડેલ ઇવેન્ટ્સ પરથી અપડેટ થાય છે, તેથી તે ઇવેંચુઅલી સુસંગત છે.
ઇવેન્ટ્સનો ક્રમ સત્યનું સ્ત્રોત તરીકે સંગ્રહ કરો, માત્ર વર્તમાન સ્થિતિ નહીં. વર્તમાન સ્થિતિ ઇવેન્ટ્સ પર ફોલ્ડ છે.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| તકનીક | લાભ | ખર્ચ |
|---|---|---|
| ઇવેંચુઅલ સુસંગતા | ઉપલબ્ધતા, સ્કેલ | સ્ટેલ વાંચન, વિરોધાભાસ |
| CQRS | વાંચન/લેખન સ્કેલ | બે મોડેલ સુસંગત રાખવા માટે |
| ઇવેંટ સોર્સિંગ | ઓડિટ, રીપ્લે, ઇતિહાસ | સ્કીમા/ઇવેંટ ઉત્ક્રાંતિ, જટિલતા |
ઇવેંટ સોર્સિંગ સર્વત્ર અપનાવશો નહીં — તે શક્તિશાળી પણ ભારે છે. તેનો ઉપયોગ ત્યાં કરો જ્યાં ઓડિટ/ઇતિહાસ ખરેખર મહત્વનું છે.
વિતરિત પ્રણાલીઓ એકસાથે મજબૂત સુસંગતા, ઉપલબ્ધતા અને વિભાજન સહનશીલતા ધરાવી શકતી નથી, તેથી વરિષ્ઠ ડિજાઇન એ પસંદ કરવા વિશે છે કે ઇવેંચુઅલ સુસંગતા ક્યાં સ્વીકાર્ય છે.
CQRS અને ઇવેંટ સોર્સિંગ તમને ઇવેંચુઅલ સુસંગતા વિશ્વાસપાત્ર અને ઓડિટ કરી શકાય તેવી બનાવવાના સાધનો આપે છે — પણ પ્રત્યેક વાસ્તવિક જટિલતા ઉમેરે છે, તેથી તેમને ચિકિત્સાગતપણે લાગુ કરો, ડિફલ્ટ પર નહીં.