ઇવેન્ટ સોર્સિંગ તમને તમારો ડેટા ઓવરરાઈટ કરવાનું બંધ કરવાનું કહે છે. પરંપરાગત CRUD એપ્લિકેશનમાં, યુઝરના શિપિંગ એડ્રેસને અપડેટ કરવાનો અર્થ છે રો (row) શોધવી, તેની કિંમત બદલવી અને અગાઉની સ્થિતિને કાઢી નાખવી. ઇવેન્ટ સોર્સિંગ એક અલગ માર્ગ અપનાવે છે. તે દરેક ફેરફારને એક અપરિવર્તનીય તથ્ય (immutable fact) તરીકે સ્ટોર કરે છે: જેમ કે યુઝરે એકાઉન્ટ બનાવ્યું, તેમનું એડ્રેસ અપડેટ કર્યું, અથવા તેમનું ઈમેલ વેરિફાય કર્યું. સિસ્ટમની વર્તમાન સ્થિતિ સીધી રીતે સ્ટોર કરવામાં આવતી નથી. તે આ ઇવેન્ટ્સને ક્રમમાં ફરીથી રજૂ (replay) કરીને ગણવામાં આવે છે.
આ પેટર્ન વાસ્તવિક સમસ્યાઓનો ઉકેલ લાવે છે. ઓડિટ ટ્રેલ્સ (Audit trails) મફત ઉપ-ઉત્પાદન (byproducts) બની જાય છે. તમે કોઈપણ ભૂતકાળના સમયે ઓર્ડરની સ્થિતિ ફરીથી બનાવી શકો છો. તમે બરાબર શું થયું હતું તેને ફરીથી રજૂ (replay) કરીને ડિબગ કરી શકો છો. તેની સામેનો નુકસાન (trade-off) જટિલતા છે. હવે તમારે સાદી રો (rows) ને બદલે તથ્યોના સ્ટ્રીમ્સ, રીડ મોડલ્સ અને ઇવેન્ચ્યુઅલ કન્સિસ્ટન્સી (eventual consistency) મેનેજ કરવી પડશે.
PostgreSQL તમારા ઇવેન્ટ સ્ટોર તરીકે કામ કરી શકે છે. મોટાભાગની ટીમો પહેલેથી જ તેનો ઉપયોગ કરતી હોય છે. તે ACID ટ્રાન્ઝેક્શન, ફ્લેક્સિબલ પેલોડ માટે JSONB અને સાબિત થયેલા બેકઅપ ટૂલ્સ ઓફર કરે છે. તમારે પહેલા જ દિવસે Kafka, Cassandra અથવા કોઈ વિશિષ્ટ ઇવેન્ટ-સ્ટોર ડેટાબેઝ લાવવાની જરૂર નથી. એક સ્ટાન્ડર્ડ Postgres ઇન્સ્ટન્સ તમને તમારા ઇન્ફ્રાસ્ટ્રક્ચરના કદમાં વધારો કર્યા વિના ઇવેન્ટ સોર્સિંગ માટે જરૂરી ટ્રાન્ઝેક્શનલ ગેરંટી અને ઓડિટ ટ્રેલ્સ આપે છે.
એક Postgres ઇવેન્ટ સ્ટોરનું સ્વરૂપ
સ્કીમા લગભગ અત્યંત સરળ હોઈ શકે છે. ઓછામાં ઓછું, તમારે એક એવી ટેબલની જરૂર છે જે ઇવેન્ટ્સ ઉમેરે (append) અને ક્યારેય તેને ઇન-પ્લેસ અપડેટ ન કરે. વ્યવહારુ ડિઝાઇન આ મુજબ દેખાય છે:
idએક bigserial અથવા UUID તરીકે, જે ગ્લોબલ ઓર્ડરિંગ તરીકે કામ કરે છે.stream_idસંબંધિત ઇવેન્ટ્સને ગ્રુપ કરવા માટે, જેમ કે કોઈ એક યુઝર અથવા ઓર્ડર માટેના તમામ ફેરફારો.event_typeપ્લેન ટેક્સ્ટ તરીકે:UserEmailChanged,PaymentReceived,InventoryAdjusted.payloadJSONB તરીકે, જે તે ઘટના માટેનો ચોક્કસ ડેટા ધરાવે છે.occurred_atટાઈમઝોન ચોકસાઈ સાથે.versionદરેક સ્ટ્રીમ માટે, જે ઓપ્ટિમીસ્ટિક કન્કરન્સી (optimistic concurrency) લાગુ કરે છે.
તમે એપ્લિકેશન કોડમાં અથવા ડેટાબેઝ કન્સ્ટ્રેન્ટ દ્વારા અપરિવર્તનીયતા (immutability) નો નિયમ લાગુ કરો છો. (stream_id, version) પર એક યુનિક ઇન્ડેક્સ બે રાઈટર્સને સમાન સિક્વન્સ નંબર ઉમેરતા અટકાવે છે. જ્યારે કોઈ કમાન્ડ આવે છે, ત્યારે તમે તે સ્ટ્રીમ માટે વર્તમાન વર્ઝન વાંચો છો, તેને વધારો છો, અને ટ્રાન્ઝેક્શનની અંદર નવી ઇવેન્ટ ઇન્સર્ટ કરો છો. જો અન્ય કોઈ પ્રોસેસ તમારા કરતા પહેલા તે કરી લે, તો યુનિક કન્સ્ટ્રેન્ટ ફેલ થાય છે, અને તમે ફરીથી પ્રયાસ કરો છો અથવા કમાન્ડને નકારી કાઢો છો.
એક નક્કર ઉદાહરણ લો. તમે ઇન્વેન્ટરી સિસ્ટમ ચલાવો છો. quantity કોલમ સાથેની સિંગલ inventory રો ને બદલે, તમે inventory_events ટેબલમાં ઇવેન્ટ્સ ઉમેરો છો. ItemReceived દસ યુનિટ ઉમેરે છે. ItemReserved બે યુનિટ દૂર કરે છે. ItemShipped ત્રણ યુનિટ દૂર કરે છે. SKU-42 માટે વર્તમાન સ્ટોક જાણવા માટે, તમે સંબંધિત ઇવેન્ટ પેલોડ્સનો સરવાળો કરો છો. ત્રણ દિવસ પહેલાનો સ્ટોક જાણવા માટે, તમે ફક્ત તે ટાઈમસ્ટેમ્પ સુધીના ઇવેન્ટ્સનો સરવાળો કરો છો. જો તમારી શિપિંગ લોજિકમાં કોઈ બગને કારણે ગયા મંગળવારે ભૂલ થઈ હોય, તો તમે સાચા સ્ટેટ મેળવવા માટે સુધારેલા કોડ દ્વારા ઇવેન્ટ્સને ફરીથી રજૂ (replay) કરી શકો છો. તમે સાદા UPDATE સ્ટેટમેન્ટ સાથે આવું કરી શકતા નથી.
સિદ્ધાંતો જે તમને મુશ્કેલીઓથી બચાવશે
Postgres પર નિર્માણ કરવાથી શિસ્તની જરૂરિયાત દૂર થતી નથી. નીચેના સિદ્ધાંતો ઇવેન્ટ-સોર્સ્ડ સિસ્ટમ્સને સીધા લાગુ પડે છે.
તેને સરળ રાખો. જટિલતા વિશ્વસનીયતાને ખતમ કરે છે. એક કાર્યકારી ફ્લો (working flow) તૈયાર કરતા પહેલા જ જનરિક ઇવેન્ટ ફ્રેમવર્ક બનાવવાની ઈચ્છાને રોકો. મૂલ્ય સાબિત કરવા માટે એક સિંગલ ટેબલ, ઇવેન્ટ્સ ઉમેરવા માટે એક રિપોઝિટરી ફંક્શન અને રીડ મોડલ્સ બનાવવા માટે એક પ્રોજેક્શન વર્કર પૂરતું છે. જ્યારે કોઈ નક્કર સમસ્યા આવે ત્યારે જ સાધનો ઉમેરો.
નાની શરૂઆત કરો. તમારા આખા મોનોલિથ (monolith) ને ફરીથી લખશો નહીં. એક એવો બાઉન્ડેડ કોન્ટેક્સ્ટ (bounded context) પસંદ કરો જ્યાં ઓડિટ ટ્રેલ તેના ઓવરહેડની ભરપાઈ કરે. બિલિંગ લેજર, વર્કફ્લો એન્જિન અથવા ઇન્વેન્ટરી રિઝર્વેશન સિસ્ટમ સારા ઉમેદવાર છે. તે એક પાઇપલાઇનને એન્ડ-ટુ-એન્ડ બનાવો. તેને પ્રોડક્શનમાં ચાલવા દો. પછી નક્કી કરો કે તેને વિસ્તારવું કે નહીં.
પહેલા સફળતાને વ્યાખ્યાયિત કરો. ઇવેન્ટ સોર્સિંગ એ ડિફોલ્ટ આર્કિટેક્ચર નથી; તે ચોક્કસ જરૂરિયાતો માટેનો ઉકેલ છે. જો તમારી જરૂરિયાત ફક્ત લેટેસ્ટ સ્ટેટને ટ્રેક કરવાની હોય, તો CRUD વધુ ઝડપી અને સસ્તું છે. જો તમારે ટેમ્પોરલ ક્વેરીઝ (temporal queries), કડક ઓડિટબિલિટી અથવા જરૂરિયાત મુજબ રીડ મોડલ્સ ફરીથી બનાવવા માટેની ક્ષમતાની જરૂર હોય, તો ઇવેન્ટ્સ યોગ્ય છે. તમે કટિબદ્ધ થાઓ તે પહેલાં જાણો કે તમે કઈ સમસ્યાનો ઉકેલ લાવી રહ્યા છો.
ઓપ્ટિમાઇઝ કરતા પહેલા માપો. સામાન્ય હાર્ડવેર પર આધુનિક PostgreSQL એક સાદી એપન્ડ-ઓન્લી (append-only) ટેબલ સાથે પ્રતિ સેકન્ડ હજારો ઇવેન્ટ્સ સ્વીકારી શકે છે. જ્યાં સુધી તમારું મોનિટરિંગ એ સાબિત ન કરે કે તમે સરળ ઉપાયોનો ઉપયોગ કરી લીધો છે, ત્યાં સુધી તમારા ઇવેન્ટ સ્ટોરને શાર્ડ (shard) કરશો નહીં અથવા જટિલ પાર્ટિશનિંગ સ્કીમ્સ રજૂ કરશો નહીં. તમે જે ફિલ્ડ્સ ક્વેરી કરો છો તેને ઇન્ડેક્સ કરો. એપન્ડ-ઓન્લી વર્કલોડ માટે autovacuum ને ટ્યુન કરો. પછી ફરીથી માપો.
બધું જ ટેસ્ટ કરો. તમારા ઇવેન્ટ હેન્ડલર્સનું યુનિટ ટેસ્ટિંગ કરો. એપન્ડ પાથ (append path) નું ઇન્ટિગ્રેશન ટેસ્ટિંગ કરો. સૌથી મહત્વનું, નિષ્ફળતાના સંજોગો (failure scenarios) ટેસ્ટ કરો. જ્યારે બે નોડ્સ એકસાથે એક જ સ્ટ્રીમમાં ડેટા એપન્ડ કરે ત્યારે શું થાય છે? જ્યારે પ્રોજેક્શન વર્કર બેચની વચ્ચે ક્રેશ થાય ત્યારે શું થાય છે? તમારા ઓપ્ટિમીસ્ટિક કન્કરન્સી (optimistic concurrency) અને એટ-લીસ્ટ-વનસ ડિલિવરી (at-least-once delivery) ગેરંટીઓની ચકાસણી કરે તેવા ટેસ્ટ લખો.
પ્રોડક્શનમાં મોનિટર કરો. ઇવેન્ટ્સ ટેબલ વધતું જશે. નોર્મલાઇઝ્ડ સ્કીમાથી વિપરીત, જ્યાં અપડેટ્સ રો કાઉન્ટને સ્થિર રાખે છે, ઇવેન્ટ સોર્સિંગ જાણીજોઈને એડિટિવ (additive) હોય છે. ટેબલનું કદ, ડિસ્ક I/O, અને તમારા રાઈટ મોડલ (write model) તથા રીડ મોડલ પ્રોજેક્શન વચ્ચેના લેગ (lag) પર નજર રાખો. તમારા યુઝર્સ જૂનો ડેટા (stale data) નો અનુભવ કરે તે પહેલાં પ્રોજેક્શન લેગ પર એલર્ટ સેટ કરો.
મેન્યુઅલ કાર્યોને ઓટોમેટ કરો. મેન્યુઅલ સ્કીમા ફેરફારો, મેન્યુઅલ પ્રોજેક્શન રીબિલ્ડ્સ અને મેન્યુઅલ ઇવેન્ટ રિપ્લે એ ટિકિંગ ટાઈમ બોમ્બ છે. તમારી માઈગ્રેશન વ્યૂહરચનાને સ્ક્રિપ્ટ કરો. જો તમે ઇવેન્ટ સ્કીમામાં ફેરફાર કરો છો, તો અપકાસ્ટિંગ (upcasting) અથવા ટ્રાન્સફોર્મેશનને ઓટોમેટ કરો જેથી મધ્યરાત્રિએ માનવીય હસ્તક્ષેપ વગર જૂની ઇવેન્ટ્સને નવા લોજિક દ્વારા રિપ્લે કરી શકાય.
તમારા નિર્ણયોનું ડોક્યુમેન્ટેશન કરો. ચોક્કસ સ્ટ્રીમ્સ શા માટે અસ્તિત્વમાં છે, દરેક ઇવેન્ટ પ્રકારનો અર્થ શું છે, અને ટીમે ઇવેન્ટ્સને બદલે ક્યારે CRUD પસંદ કરવું જોઈએ તે લખો. ઇવેન્ટ સોર્સિંગ કોગ્નિટિવ લોડ (cognitive load) વધારે છે. સારું ડોક્યુમેન્ટેશન નવા એન્જિનિયરને ખોટી ધારણા લગાવતા અને ક્રિટિકલ સ્ટ્રીમમાં ખોટી રીતે બનાવેલી (malformed) ઇવેન્ટ્સ એપન્ડ કરતા અટકાવે છે.
મહિનાઓ બગાડતા છટકાવ (Traps)
ઇવેન્ટ સોર્સિંગ ડાયાગ્રામમાં સુંદર લાગે છે પરંતુ પ્રોડક્શનમાં પીડાદાયક સાબિત થઈ શકે છે. આ છટકાવથી સાવધ રહો.
જટિલતાને ઓછી આંકવી. સ્ટેટ ફરીથી બનાવવા માટે ઇવેન્ટ્સ રિપ્લે કરવી તે વૈચારિક રીતે સરળ છે. પરંતુ આઈડેમપોટન્સી (idempotency) મેનેજ કરવી, પર્ફોર્મન્સ માટે સ્નેપશોટિંગ કરવું અને એગ્રીગેટ્સમાં કોમ્પેન્સેટિંગ ટ્રાન્ઝેક્શન સંભાળવા તે સરળ નથી. તમારા સિસ્ટમને નાના ભાગોમાં વહેંચો. એક સમયે એક સ્ટ્રીમ ઉકેલો.
ઓવર-એન્જિનિયરિંગ. માત્ર એવું વિચારીને મલ્ટી-નોડ Kafka ક્લસ્ટર ન બનાવો કે ભવિષ્યમાં ઇવેન્ટ વોલ્યુમ વધશે. Postgres તમને આશ્ચર્યજનક રીતે લાંબા સમય સુધી સાથ આપી શકે છે. નવું ઇન્ફ્રાસ્ટ્રક્ચર ત્યારે જ લાવો જ્યારે તમારી પાસે એવો માપન કરેલો બોટલનેક (bottleneck) હોય જેને તમે તમારા વર્તમાન સેટઅપમાં ઠીક કરી શકતા નથી.
ટેકનિકલ ડેબ્ટ (technical debt) ને અવગણવું. જૂની ઇવેન્ટ સ્કીમા હંમેશા માટે રહી જાય છે. જો તમે તમારા OrderCreated પેલોડમાં ફેરફાર કરો છો, તો પણ તમારી પાસે જૂના સ્વરૂપમાં દસ મિલિયન ઐતિહાસિક ઇવેન્ટ્સ હશે. આ દેવા (debt) પર નજર રાખો. બેકવર્ડ-કમ્પેટેબલ રીડર્સ અથવા માઈગ્રેશન સ્ક્રિપ્ટ્સનું આયોજન કરો. લેગસી ઇવેન્ટ્સના બોજને કારણે દરેક નવા ફીચરની ગતિ ધીમી ન પડવા દો.
એવા સાધનો પસંદ કરવા જે ટીમ ચલાવી ન શકે. જો માત્ર એક જ વ્યક્તિ આર્કિટેક્ચર સમજી શકે છે, તો શ્રેષ્ઠ આર્કિટેક્ચર પણ નિષ્ફળ જાય છે. જો તમારી ટીમ Postgres અને SQL જાણતી હોય, તો ત્યાંથી શરૂઆત કરો. જો તમે સ્પેશિયલાઇઝ્ડ ઇવેન્ટ સ્ટોર રજૂ કરો છો, તો ખાતરી કરો કે તમારી પાસે વહેલી સવારે બે વાગ્યે તેને ડિબગ કરવાની ઓપરેશનલ કુશળતા છે.
એક વ્યવહારુ શરૂઆતનું બિંદુ
જો આ અભિગમ તમારી સમસ્યા માટે યોગ્ય હોય, તો પાંચ ક્વાર્ટરના રીરાઈટ (rewrite) ની રાહ ન જુઓ. આ અઠવાડિયે જ શરૂ કરો.
તમારી વર્તમાન સિસ્ટમ્સનું ઓડિટ કરો. એવી જગ્યા શોધો જ્યાં ઓડિટ ટ્રેલ (audit trail) વાસ્તવિક સમસ્યા હલ કરી શકે. કદાચ તે ઓર્ડર સ્ટેટ મશીન હોય જે હાલમાં માત્ર એક જ status કોલમ ધરાવે છે. કદાચ તે કોઈ ફાઇનાન્શિયલ લેજર હોય જ્યાં બેલેન્સ સુધારવા માટે મેન્યુઅલ ડેટાબેઝ પેચની જરૂર પડતી હોય. એવી એક ખામી પસંદ કરો જ્યાં સ્ટેટ ઓવરરાઈટ કરવાથી તમને નુકસાન થયું હોય.
પછી આજે તમે કરી શકો તેવો એક નાનો સુધારો પસંદ કરો. એક ઇવેન્ટ ટેબલ બનાવો. એક સ્ટ્રીમ મોડેલ કરો. એક પ્રોજેક્શન લખો જે તે ઇવેન્ટ્સમાંથી રીડ મોડલ બનાવે. તેને ફીચર ફ્લેગ (feature flag) પાછળ ડિપ્લોય કરો. તેને વાસ્તવિક ટ્રાફિક હેન્ડલ કરતા જુઓ.
PostgreSQL સાથે ઇવેન્ટ સોર્સિંગ કોઈ જાદુ નથી. તે એવી ટીમો માટે એક વ્યવહારુ સાધન છે જેમને માત્ર વસ્તુઓ ક્યાં છે તે જ નહીં, પરંતુ તે ત્યાં કેવી રીતે પહોંચી તે પણ જાણવાની જરૂર છે. ધીમે ધીમે બનાવો, પ્રમાણિકતાથી માપો, અને તમારી વાસ્તવિક જરૂરિયાતોને આર્કિટેક્ચરનું માર્ગદર્શન કરવા દો.