Event sourcing നിങ്ങളുടെ ഡാറ്റ ഓവർറൈറ്റ് ചെയ്യുന്നത് നിർത്താൻ ആവശ്യപ്പെടുന്നു. ഒരു പരമ്പരാഗത CRUD ആപ്ലിക്കേഷനിൽ, ഒരു ഉപയോക്താവിന്റെ ഷിപ്പിംഗ് അഡ്രസ്സ് അപ്‌ഡേറ്റ് ചെയ്യുക എന്നാൽ ആ റോ (row) കണ്ടെത്തി, മൂല്യം മാറ്റുകയും, പഴയ അവസ്ഥ ഒഴിവാക്കുകയും ചെയ്യുക എന്നാണ് അർത്ഥം. Event sourcing ഇതിൽ നിന്നും വ്യത്യസ്തമായ ഒരു പാത സ്വീകരിക്കുന്നു. ഇത് ഓരോ മാറ്റത്തെയും മാറ്റം വരുത്താൻ കഴിയാത്ത ഒരു വസ്തുതയായി (immutable fact) സംഭരിക്കുന്നു: ഒരു ഉപയോക്താവ് ഒരു അക്കൗണ്ട് നിർമ്മിച്ചു, അവരുടെ അഡ്രസ്സ് അപ്‌ഡേറ്റ് ചെയ്തു, അവരുടെ ഇമെയിൽ വെരിഫൈ ചെയ്തു എന്നിങ്ങനെ. സിസ്റ്റത്തിന്റെ നിലവിലെ അവസ്ഥ നേരിട്ട് സംഭരിക്കപ്പെടുന്നില്ല. പകരം, ഈ ഇവന്റുകൾ ക്രമമായി വീണ്ടും പ്രവർത്തിപ്പിച്ചുകൊണ്ട് (replaying) അത് കണക്കാക്കുന്നു.

ഈ പാറ്റേൺ യഥാർത്ഥ പ്രശ്നങ്ങൾക്ക് പരിഹാരം കാണുന്നു. ഓഡിറ്റ് ട്രയലുകൾ (Audit trails) ഇതിന്റെ സ്വാഭാവികമായ ഉപോൽപ്പന്നങ്ങളായി മാറുന്നു. ഒരു ഓർഡറിന്റെ അവസ്ഥ ഏത് മുൻകാല നിമിഷത്തിലും നിങ്ങൾക്ക് പുനർനിർമ്മിക്കാൻ കഴിയും. എന്താണ് സംഭവിച്ചതെന്ന് കൃത്യമായി വീണ്ടും പ്രവർത്തിപ്പിച്ചുകൊണ്ട് നിങ്ങൾക്ക് ഡീബഗ് ചെയ്യാം. ഇതിന്റെ വെല്ലുവിളി സങ്കീർണ്ണതയാണ്. ഇപ്പോൾ നിങ്ങൾ ലളിതമായ റോകൾക്ക് പകരം വസ്തുതകളുടെ സ്ട്രീമുകളും (streams of facts), റീഡ് മോഡലുകളും (read models), ഇവൻച്വൽ കൺസിസ്റ്റൻസിയും (eventual consistency) കൈകാര്യം ചെയ്യേണ്ടി വരുന്നു.

PostgreSQL-ന് നിങ്ങളുടെ ഇവന്റ് സ്റ്റോർ ആയി പ്രവർത്തിക്കാൻ കഴിയും. മിക്ക ടീമുകളും ഇതിനകം തന്നെ ഇത് ഉപയോഗിക്കുന്നുണ്ട്. ഇത് ACID ട്രാൻസാക്ഷനുകൾ, ഫ്ലെക്സിബിൾ പേലോഡുകൾക്കായി JSONB, തെളിയിക്കപ്പെട്ട ബാക്കപ്പ് ടൂളുകൾ എന്നിവ വാഗ്ദാനം ചെയ്യുന്നു. ആദ്യ ദിവസം തന്നെ Kafka, Cassandra അല്ലെങ്കിൽ ഒരു പ്രത്യേക ഇവന്റ്-സ്റ്റോർ ഡാറ്റാബേസ് എന്നിവ കൊണ്ടുവരേണ്ടതില്ല. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ വിപുലീകരിക്കാതെ തന്നെ, Event sourcing-ന് ആവശ്യമായ ട്രാൻസാക്ഷണൽ ഗ്യാരണ്ടികളും ഓഡിറ്റ് ട്രയലുകളും ഒരു സ്റ്റാൻഡേർഡ് Postgres ഇൻസ്റ്റൻസ് നിങ്ങൾക്ക് നൽകുന്നു.

The Shape of a Postgres Event Store

ഇതിന്റെ സ്കീമ (schema) വളരെ ലളിതമായിരിക്കാം. കുറഞ്ഞപക്ഷം, ഇവന്റുകൾ ചേർക്കുകയും (append) അവ ഒരിക്കലും മാറ്റം വരുത്താതെ (update) സൂക്ഷിക്കുകയും ചെയ്യുന്ന ഒരു ടേബിൾ നിങ്ങൾക്ക് ആവശ്യമാണ്. ഒരു പ്രായോഗിക രൂപം ഇപ്രകാരമാണ്:

  • id ഒരു bigserial അല്ലെങ്കിൽ UUID ആയി, ഇത് ആഗോള ക്രമീകരണത്തിനായി (global ordering) ഉപയോഗിക്കുന്നു.
  • stream_id ബന്ധപ്പെട്ട ഇവന്റുകളെ ഗ്രൂപ്പ് ചെയ്യാൻ, ഉദാഹരണത്തിന് ഒരു ഉപയോക്താവിനോ ഓർഡറിനോ വേണ്ടിയുള്ള എല്ലാ മാറ്റങ്ങളും.
  • event_type പ്ലെയിൻ ടെക്സ്റ്റ് ആയി: UserEmailChanged, PaymentReceived, InventoryAdjusted.
  • payload JSONB ആയി, ആ സംഭവത്തിന്റെ പ്രത്യേക ഡാറ്റ സൂക്ഷിക്കുന്നു.
  • occurred_at ടൈംസോൺ കൃത്യതയോടെ.
  • version ഓരോ സ്ട്രീമിനും, ഇത് ഒപ്റ്റിമിസ്റ്റിക് കൺകറൻസി (optimistic concurrency) ഉറപ്പാക്കുന്നു.

ആപ്ലിക്കേഷൻ കോഡിലൂടെയോ ഡാറ്റാബേസ് കൺസ്ട്രയിന്റിലൂടെയോ നിങ്ങൾക്ക് ഇമ്മ്യൂട്ടബിലിറ്റി (immutability) നിയമം നടപ്പിലാക്കാം. (stream_id, version) എന്നിവയിൽ ഒരു യുണീക് ഇൻഡക്സ് (unique index) നൽകുന്നത് രണ്ട് ആളുകൾ ഒരേ സീക്വൻസ് നമ്പർ ചേർക്കുന്നത് തടയും. ഒരു കമാൻഡ് വരുമ്പോൾ, നിങ്ങൾ ആ സ്ട്രീമിനായുള്ള നിലവിലെ വേർഷൻ വായിക്കുന്നു, അത് വർദ്ധിപ്പിക്കുന്നു, തുടർന്ന് ഒരു ട്രാൻസാക്ഷനുള്ളിൽ പുതിയ ഇവന്റ് ഇൻസേർട്ട് ചെയ്യുന്നു. മറ്റൊരു പ്രക്രിയ നിങ്ങളേക്കാൾ മുമ്പ് ഇത് ചെയ്തതെങ്കിൽ, യുണീക് കൺസ്ട്രയിന്റ് പരാജയപ്പെടും, അപ്പോൾ നിങ്ങൾ അത് വീണ്ടും ശ്രമിക്കുകയോ കമാൻഡ് നിരസിക്കുകയോ ചെയ്യാം.

ഒരു ഉദാഹരണം പരിശോധിക്കാം. നിങ്ങൾ ഒരു ഇൻവെന്ററി സിസ്റ്റം നടത്തുന്നു എന്ന് കരുതുക. quantity എന്ന കോളം ഉള്ള ഒരു സിംഗിൾ inventory റോയ്ക്ക് പകരം, നിങ്ങൾ inventory_events എന്ന ടേബിളിലേക്ക് ഇവന്റുകൾ ചേർക്കുന്നു. ItemReceived പത്ത് യൂണിറ്റുകൾ കൂട്ടുന്നു. ItemReserved രണ്ട് യൂണിറ്റുകൾ കുറയ്ക്കുന്നു. ItemShipped മൂന്ന് യൂണിറ്റുകൾ കുറയ്ക്കുന്നു. SKU-42-ന്റെ നിലവിലെ സ്റ്റോക്ക് അറിയാൻ, നിങ്ങൾ പ്രസക്തമായ ഇവന്റ് പേലോഡുകൾ കൂട്ടിയാൽ മതി. മൂന്ന് ദിവസം മുമ്പുള്ള സ്റ്റോക്ക് അറിയാൻ, ആ ടൈംസ്റ്റാമ്പ് വരെയുള്ള ഇവന്റുകൾ മാത്രം കൂട്ടുക. കഴിഞ്ഞ ചൊവ്വാഴ്ച നിങ്ങളുടെ ഷിപ്പിംഗ് ലോജിക്കിലെ ഒരു ബഗ് കാരണം പിശക് സംഭവിച്ചുവെങ്കിൽ, ശരിയായ കോഡ് ഉപയോഗിച്ച് ഇവന്റുകൾ വീണ്ടും പ്രവർത്തിപ്പിച്ചുകൊണ്ട് യഥാർത്ഥ അവസ്ഥ കണ്ടെത്താം. ഒരു ലളിതമായ UPDATE സ്റ്റേറ്റ്‌മെന്റ് ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയില്ല.

Principles That Keep You Out of Trouble

Postgres ഉപയോഗിച്ച് നിർമ്മിക്കുന്നത് അച്ചടക്കത്തിന്റെ ആവശ്യകത ഇല്ലാതാക്കുന്നില്ല. താഴെ പറയുന്ന തത്വങ്ങൾ ഇവന്റ് സോഴ്സ്ഡ് സിസ്റ്റങ്ങൾക്ക് നേരിട്ട് ബാധകമാണ്.

Keep it simple. സങ്കീർണ്ണത വിശ്വാസ്യതയെ ഇല്ലാതാക്കുന്നു. ഒരു വർക്കിംഗ് ഫ്ലോ പോലും പൂർത്തിയാക്കുന്നതിന് മുമ്പ് ഒരു ജനറിക് ഇവന്റ് ഫ്രെയിംവർക്ക് നിർമ്മിക്കാനുള്ള പ്രേരണയെ പ്രതിരോധിക്കുക. ഒരു ടേബിൾ, ഇവന്റുകൾ ചേർക്കാനുള്ള ഒരു റെപ്പോസിറ്ററി ഫംഗ്ഷൻ, റീഡ് മോഡലുകൾ നിർമ്മിക്കാനുള്ള ഒരു പ്രൊജക്ഷൻ വർക്കർ എന്നിവ അതിന്റെ മൂല്യം തെളിയിക്കാൻ മതിയാകും. ഒരു യഥാർത്ഥ പ്രശ്നം ഉണ്ടാകുമ്പോൾ മാത്രം പുതിയ ടൂളുകൾ ചേർക്കുക.

Start small. നിങ്ങളുടെ മുഴുവൻ മോണോലിത്തും (monolith) മാറ്റിയെഴുതരുത്. ഓഡിറ്റ് ട്രയൽ അതിന്റെ അധികഭാരം നികത്തുന്ന ഒരു ബൗണ്ടഡ് കോൺടെക്സ്റ്റ് (bounded context) തിരഞ്ഞെടുക്കുക. ഒരു ബില്ലിംഗ് ലെഡ്ജർ, ഒരു വർക്ക്ഫ്ലോ എഞ്ചിൻ, അല്ലെങ്കിൽ ഒരു ഇൻവെന്ററി റിസർവേഷൻ സിസ്റ്റം എന്നിവ നല്ല ഉദാഹരണങ്ങളാണ്. ആ ഒരു പൈപ്പ്‌ലൈൻ പൂർണ്ണമായും നിർമ്മിക്കുക. അത് പ്രൊഡക്ഷനിൽ പ്രവർത്തിക്കാൻ അനുവദിക്കുക. അതിനുശേഷം വിപുലീകരിക്കണോ എന്ന് തീരുമാനിക്കുക.

Define success first. Event sourcing എന്നത് ഒരു ഡിഫോൾട്ട് ആർക്കിടെക്ചർ അല്ല; അത് പ്രത്യേക ആവശ്യങ്ങൾക്കുള്ള ഒരു പരിഹാരമാണ്. നിങ്ങളുടെ ആവശ്യം ഏറ്റവും പുതിയ അവസ്ഥ മാത്രം ട്രാക്ക് ചെയ്യുക എന്നതാണെങ്കിൽ, CRUD ആണ് വേഗതയേറിയതും ചിലവ് കുറഞ്ഞതും. നിങ്ങൾക്ക് ടെമ്പറൽ ക്വറികൾ (temporal queries), കർശനമായ ഓഡിറ്റബിലിറ്റി, അല്ലെങ്കിൽ ആവശ്യാനുസരണം റീഡ് മോഡലുകൾ പുനർനിർമ്മിക്കാനുള്ള കഴിവ് എന്നിവ ആവശ്യമാണെങ്കിൽ, ഇവന്റുകൾ ഉപയോഗിക്കുന്നത് യുക്തിസഹമാണ്. ഏത് പ്രശ്നമാണ് നിങ്ങൾ പരിഹരിക്കുന്നത് എന്ന് ഉറപ്പുവരുത്തിയ ശേഷം മാത്രം ഇതിലേക്ക് കടക്കുക.

Measure before you optimize. മിതമായ ഹാർഡ്‌വെയറിലുള്ള ആധുനിക PostgreSQL-ന് ഒരു സിംപിൾ അപ്പെൻഡ്-ഒൺലി (append-only) ടേബിൾ ഉപയോഗിച്ച് സെക്കൻഡിൽ ആയിരക്കണക്കിന് ഇവന്റുകൾ സ്വീകരിക്കാൻ കഴിയും. നിങ്ങളുടെ മോണിറ്ററിംഗ് ലളിതമായ പരിഹാരങ്ങൾ പരാജയപ്പെട്ടുവെന്ന് തെളിയിക്കുന്നത് വരെ നിങ്ങളുടെ ഇവന്റ് സ്റ്റോർ ഷാർഡ് (shard) ചെയ്യുകയോ സങ്കീർണ്ണമായ പാർട്ടീഷനിംഗ് സ്കീമുകൾ കൊണ്ടുവരികയോ ചെയ്യരുത്. നിങ്ങൾ ക്വറി ചെയ്യുന്ന ഫീൽഡുകൾ ഇൻഡക്സ് ചെയ്യുക. അപ്പെൻഡ്-ഒൺലി വർക്ക്ലോഡുകൾക്കായി autovacuum ട്യൂൺ ചെയ്യുക. അതിനുശേഷം വീണ്ടും അളക്കുക.

എല്ലാം പരിശോധിക്കുക. നിങ്ങളുടെ ഇവന്റ് ഹാൻഡ്‌ലറുകൾ (event handlers) യൂണിറ്റ് ടെസ്റ്റ് ചെയ്യുക. അപ്പൻഡ് പാത്ത് (append path) ഇന്റഗ്രേഷൻ ടെസ്റ്റ് ചെയ്യുക. ഏറ്റവും പ്രധാനമായി, പരാജയസാധ്യതകൾ (failure scenarios) പരിശോധിക്കുക. രണ്ട് നോഡുകൾ ഒരേസമയം ഒരേ സ്ട്രീമിലേക്ക് അപ്പൻഡ് ചെയ്താൽ എന്ത് സംഭവിക്കും? ഒരു പ്രൊജക്ഷൻ വർക്കർ (projection worker) ബാച്ച് പ്രക്രിയയ്ക്കിടെ തകരാറിലായാൽ എന്ത് സംഭവിക്കും? നിങ്ങളുടെ ഒപ്റ്റിമിസ്റ്റിക് കൺകറൻസി (optimistic concurrency), അറ്റ്-ലീസ്റ്റ്-വൺസ് ഡെലിവറി (at-least-once delivery) ഗ്യാരണ്ടികൾ എന്നിവ പരിശോധിക്കുന്ന ടെസ്റ്റുകൾ എഴുതുക.

പ്രൊഡക്ഷനിൽ നിരീക്ഷിക്കുക. ഇവന്റ്സ് ടേബിൾ വലുതായിക്കൊണ്ടിരിക്കും. അപ്‌ഡേറ്റുകൾ നടത്തുമ്പോൾ വരികളുടെ എണ്ണം (row counts) മാറാത്ത നോർമലൈസ്ഡ് സ്കീമകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഇവന്റ് സോഴ്സിംഗ് ബോധപൂർവ്വം അഡിറ്റീവ് (additive) ആണ്. ടേബിൾ സൈസ്, ഡിസ്ക് I/O, നിങ്ങളുടെ റൈറ്റ് മോഡലും (write model) റീഡ് മോഡൽ പ്രൊജക്ഷനുകളും (read model projections) തമ്മിലുള്ള ലാഗ് (lag) എന്നിവ ട്രാക്ക് ചെയ്യുക. ഉപയോക്താക്കൾ പഴയ ഡാറ്റ (stale data) ശ്രദ്ധിക്കുന്നതിന് മുമ്പ് തന്നെ പ്രൊജക്ഷൻ ലാഗിനായി അലേർട്ടുകൾ സജ്ജീകരിക്കുക.

മാനുവൽ ജോലികൾ ഓട്ടോമേറ്റ് ചെയ്യുക. മാനുവൽ സ്കീമ മാറ്റങ്ങൾ, മാനുവൽ പ്രൊജക്ഷൻ റീബിൽഡുകൾ, മാനുവൽ ഇവന്റ് റീപ്ലേ എന്നിവ അപകടകാരികളായ സാഹചര്യങ്ങളാണ്. നിങ്ങളുടെ മൈഗ്രേഷൻ സ്ട്രാറ്റജി സ്ക്രിപ്റ്റ് ചെയ്യുക. നിങ്ങൾ ഒരു ഇവന്റ് സ്കീമ പരിഷ്കരിക്കുകയാണെങ്കിൽ, അർദ്ധരാത്രിയിൽ മനുഷ്യസഹായമില്ലാതെ തന്നെ പഴയ ഇവന്റുകൾ പുതിയ ലോജിക് വഴി റീപ്ലേ ചെയ്യാൻ സാധിക്കുന്ന രീതിയിൽ അപ്‌കാസ്റ്റിംഗോ (upcasting) ട്രാൻസ്ഫോർമേഷനോ ഓട്ടോമേറ്റ് ചെയ്യുക.

നിങ്ങളുടെ തീരുമാനങ്ങൾ രേഖപ്പെടുത്തുക. പ്രത്യേക സ്ട്രീമുകൾ എന്തിനാണ് നിലനിൽക്കുന്നത്, ഓരോ ഇവന്റ് ടൈപ്പും എന്താണ് അർത്ഥമാക്കുന്നത്, എപ്പോഴാണ് ടീം ഇവന്റുകൾക്ക് പകരം CRUD തിരഞ്ഞെടുക്കേണ്ടത് എന്നിവ എഴുതി വെക്കുക. ഇവന്റ് സോഴ്സിംഗ് മാനസികമായ ജോലിഭാരം (cognitive load) വർദ്ധിപ്പിക്കുന്നു. നല്ല ഡോക്യുമെന്റേഷൻ ഉണ്ടെങ്കിൽ, പുതിയൊരു എഞ്ചിനീയർ തെറ്റായ ഊഹങ്ങളിൽ എത്തിപ്പെട്ടോ കൃത്യമല്ലാത്ത ഇവന്റുകൾ (malformed events) ഒരു പ്രധാന സ്ട്രീമിലേക്ക് ചേർക്കുന്നതിൽ നിന്നും ഒഴിവാക്കാം.

മാസങ്ങൾ പാഴാക്കുന്ന കെണികൾ

ഇവന്റ് സോഴ്സിംഗ് ഒരു ഡയഗ്രാമിൽ കാണാൻ വളരെ മനോഹരമായി തോന്നുമെങ്കിലും പ്രൊഡക്ഷനിൽ അത് പ്രയാസകരമായേക്കാം. ഈ കെണികൾ ശ്രദ്ധിക്കുക.

സങ്കീർണ്ണതയെ കുറച്ചുകാണുക. സ്റ്റേറ്റ് റീബിൽഡ് ചെയ്യാൻ ഇവന്റുകൾ റീപ്ലേ ചെയ്യുന്നത് ആശയപരമായി ലളിതമാണ്. എന്നാൽ ഐഡംപോറ്റൻസി (idempotency) കൈകാര്യം ചെയ്യുന്നതും, പെർഫോമൻസിനായി സ്നാപ്‌ഷോട്ട് (snapshotting) എടുക്കുന്നതും, അഗ്രഗേറ്റുകൾക്കിടയിലുള്ള കോമ്പൻസേറ്റിംഗ് ട്രാൻസാക്ഷനുകളും (compensating transactions) അത്ര ലളിതമല്ല. നിങ്ങളുടെ സിസ്റ്റത്തെ ചെറിയ ഭാഗങ്ങളായി തിരിക്കുക. ഓരോ സ്ട്രീമും ഓരോന്നായി പരിഹരിക്കുക.

ഓവർ-എഞ്ചിനീയറിംഗ്. ഭാവിയിൽ ഇവന്റ് വോളിയം കൂടുമെന്ന് കരുതി ഇപ്പോൾ തന്നെ ഒരു മൾട്ടി-നോഡ് കാഫ്ക (Kafka) ക്ലസ്റ്റർ സജ്ജീകരിക്കരുത്. പോസ്റ്റ്‌ഗ്രെസ് (Postgres) നിങ്ങൾക്ക് അത്ഭുതകരമായ രീതിയിൽ വലിയ രീതിയിൽ സഹായിക്കും. നിലവിലെ സംവിധാനത്തിൽ പരിഹരിക്കാൻ കഴിയാത്ത ഒരു തടസ്സം (bottleneck) നേരിട്ട് കണ്ടുപിടിച്ചാൽ മാത്രം പുതിയ ഇൻഫ്രാസ്ട്രക്ചർ കൊണ്ടുവരിക.

ടെക്നിക്കൽ ഡെബ്റ്റ് (technical debt) അവഗണിക്കുക. പഴയ ഇവന്റ് സ്കീമകൾ എന്നും നിലനിൽക്കും. നിങ്ങൾ നിങ്ങളുടെ OrderCreated പേലോഡ് (payload) മാറ്റിയാലും, പഴയ രൂപത്തിലുള്ള ദശലക്ഷക്കണക്കിന് ഹിസ്റ്റോറിക്കൽ ഇവന്റുകൾ അവിടെത്തന്നെ ഉണ്ടാകും. ഈ ഡെബ്റ്റ് ട്രാക്ക് ചെയ്യുക. ബാക്ക്വേർഡ് കംപാറ്റിബിൾ (backward-compatible) റീഡറുകളോ മൈഗ്രേഷൻ സ്ക്രിപ്റ്റുകളോ പ്ലാൻ ചെയ്യുക. പഴയ ഇവന്റുകളുടെ ഭാരം പുതിയ ഫീച്ചറുകളുടെ വേഗത കുറയ്ക്കാൻ അനുവദിക്കരുത്.

ടീമിന് കൈകാര്യം ചെയ്യാൻ കഴിയാത്ത ടൂളുകൾ തിരഞ്ഞെടുക്കുക. മികച്ച ഒരു ആർക്കിടെക്ചർ ആണെങ്കിലും അത് ഒരാൾക്ക് മാത്രമേ മനസ്സിലാകുന്നുള്ളൂ എങ്കിൽ അത് പരാജയപ്പെടും. നിങ്ങളുടെ ടീമിന് Postgres-ഉം SQL-ഉം അറിയാമെങ്കിൽ അവിടെ നിന്ന് തുടങ്ങുക. നിങ്ങൾ ഒരു സ്പെഷ്യലൈസ്ഡ് ഇവന്റ് സ്റ്റോർ (specialized event store) കൊണ്ടുവരികയാണെങ്കിൽ, പുലർച്ചെ രണ്ട് മണിക്ക് പോലും അത് ഡീബഗ് ചെയ്യാൻ ആവശ്യമായ പ്രവർത്തന വൈദഗ്ധ്യം (operational expertise) നിങ്ങൾക്ക് ഉണ്ടെന്ന് ഉറപ്പുവരുത്തുക.

പ്രായോഗികമായ ഒരു തുടക്കം

ഈ രീതി നിങ്ങളുടെ പ്രശ്നത്തിന് അനുയോജ്യമാണെങ്കിൽ, അഞ്ച് ക്വാർട്ടർ നീണ്ടുനിൽക്കുന്ന റീറൈറ്റിനായി കാത്തുനിൽക്കരുത്. ഈ ആഴ്ച തന്നെ തുടങ്ങുക.

നിങ്ങളുടെ നിലവിലെ സിസ്റ്റങ്ങൾ ഓഡിറ്റ് ചെയ്യുക. ഒരു ഓഡിറ്റ് ട്രയൽ (audit trail) വഴി പരിഹരിക്കാൻ കഴിയുന്ന പ്രശ്നങ്ങൾ കണ്ടെത്തുക. ഒരുപക്ഷേ നിലവിൽ ഒരു status കോളം മാത്രം ഉപയോഗിക്കുന്ന ഒരു ഓർഡർ സ്റ്റേറ്റ് മെഷീൻ ആകാം അത്. അല്ലെങ്കിൽ ബാലൻസ് തിരുത്തലുകൾക്കായി മാനുവൽ ഡാറ്റാബേസ് പാച്ചുകൾ ആവശ്യമായി വരുന്ന ഒരു ഫിനാൻഷ്യൽ ലെഡ്ജർ ആകാം. സ്റ്റേറ്റ് ഓവർറൈറ്റ് ചെയ്യുന്നത് (overwriting state) നിങ്ങൾക്ക് ബുദ്ധിമുട്ടുണ്ടാക്കിയ ഒരു സാഹചര്യം തിരഞ്ഞെടുക്കുക.

തുടർന്ന് ഇന്ന് നിങ്ങൾക്ക് ചെയ്യാൻ കഴിയുന്ന ഒരു ചെറിയ മാറ്റം തിരഞ്ഞെടുക്കുക. ഒരു ഇവന്റ് ടേബിൾ നിർമ്മിക്കുക. ഒരു സ്ട്രീം മോഡൽ ചെയ്യുക. ആ ഇവന്റുകളിൽ നിന്ന് ഒരു റീഡ് മോഡൽ നിർമ്മിക്കുന്ന ഒരു പ്രൊജക്ഷൻ എഴുതുക. ഒരു ഫീച്ചർ ഫ്ലാഗിന് (feature flag) പിന്നിൽ ഇത് ഡിപ്ലോയ് ചെയ്യുക. യഥാർത്ഥ ട്രാഫിക് കൈകാര്യം ചെയ്യുന്നത് നിരീക്ഷിക്കുക.

PostgreSQL ഉപയോഗിച്ചുള്ള ഇവന്റ് സോഴ്സിംഗ് ഒരു മാന്ത്രികവിദ്യയല്ല. കാര്യങ്ങൾ എവിടെയാണെന്ന് മാത്രമല്ല, അവ എങ്ങനെ അവിടെ എത്തി എന്ന് അറിയേണ്ട ടീമുകൾക്കുള്ള പ്രായോഗികമായ ഒരു ഉപകരണമാണിത്. സാവധാനം നിർമ്മിക്കുക, സത്യസന്ധമായി അളക്കുക, നിങ്ങളുടെ യഥാർത്ഥ ആവശ്യകതകൾ ആർക്കിടെക്ചറിനെ നയിക്കാൻ അനുവദിക്കുക.

Source: https://dev.to/therizwansaleem/event-sourcing-with-postgresql-using-the-database-as-an-event-store-2kd4