Event sourcing: শুধু বর্তমান অবস্থা নয়, event রাখুন
শুধু সর্বশেষ balance না রেখে event sourcing প্রতিটি জমা ও উত্তোলন রাখে। এতে পূর্ণ ইতিহাস মেলে, আর কিছু নতুন সমস্যাও আসে।
সাধারণ database-এ আপনি বর্তমান অবস্থা রাখেন: ব্যাংক অ্যাকাউন্টের row বলে balance = 700। বদলালে পুরোনো মান মুছে যায়। Event sourcing তার বদলে event-এর ক্রম রাখে: Deposited 1000, Withdrew 300। বর্তমান অবস্থা বের হয় এগুলো replay করে।
Event store
Event-এর append-only log, প্রতিটিতে ID, ধরন, সময়, data আর কোন entity-র তা থাকে। Event অপরিবর্তনীয় সত্য: কখনো edit বা delete করা হয় না। ভুল ঠিক করতে নতুন সংশোধনী event যোগ করা হয়।
State পুনর্গঠন
অ্যাকাউন্টের balance পেতে তার event ক্রমে লোড করে প্রয়োগ করুন: ০ থেকে শুরু, ১০০০ যোগ, ৩০০ বিয়োগ, ফল ৭০০। দীর্ঘ ইতিহাসে snapshot ব্যবহার করুন: প্রতি N event-এ অবস্থা সেভ করুন এবং তার পরের event-ই শুধু replay করুন।
সুবিধা
- পূর্ণ audit trail বিনামূল্যে। কী হয়েছে ও কখন, জানা যায়, যা অর্থ, স্বাস্থ্য ও নিরাপত্তায় মানানসই।
- সময়ে ভ্রমণ: অতীতের যেকোনো মুহূর্তের অবস্থা পুনর্গঠন, আসল ইতিহাস replay করে debug।
- পরে নতুন view: পুরোনো event থেকে নতুন read model বা report বানানো।
- CQRS-এর সাথে স্বাভাবিক মিল: event read model ও অন্য service-কে খাওয়ায়।
খরচ
- জটিলতা বেশি এবং ভাবনার ধরন আলাদা।
- Event schema বদল: পুরোনো event চিরকাল থাকে, তাই ফরম্যাট বদলালে versioning ও upcasting লাগে।
- Read model-এ eventual consistency।
- Event-এর ওপর সরাসরি query কঠিন, তাই প্রায় সবসময় read model লাগে।
- গোপনীয়তা: অপরিবর্তনীয় event "আমার data মুছুন" অনুরোধের সাথে সংঘাতে যায়। আগে থেকে ভাবুন, যেমন ফেলে দেওয়া যায় এমন encryption key দিয়ে।
কখন ব্যবহার করবেন
যেখানে ইতিহাস সত্যিই গুরুত্বপূর্ণ: payment, ledger, order, inventory, audit-ভারী সিস্টেম। সাধারণ ব্লগ বা CRUD admin-এ সাধারণ table আর একটি audit table যথেষ্ট।
মূল কথা: Event sourcing ইতিহাসকে সত্যের উৎস বানায়। যেখানে ইতিহাসের আসল মূল্য আছে সেখানে ব্যবহার করুন, আর versioning ও read model-এর জন্য তৈরি থাকুন।
System Design সিরিজ, পর্ব ২ (building block): 13 নম্বর (মোট 14)। আগের লেখা: CQRS: read আর write আলাদা করা.
