ইভেন্ট সোর্সিং ও CQRS

১ · Event Sourcing — স্টেট নয়, ইতিহাস সংরক্ষণ করা

সাধারণ ডেটাবেস ডিজাইনে (DBMS কোর্স) আমরা শুধু বর্তমান স্টেট সংরক্ষণ করি — যেমন একটি অ্যাকাউন্টের ব্যালেন্স কলামে সরাসরি "৳১৩০" লেখা থাকে। প্রতিটি নতুন লেনদেনে সেই মানটি ওভাররাইট হয়ে যায়, এবং পুরনো মান চিরতরে হারিয়ে যায়। Event SourcingEvent Sourcingবর্তমান স্টেট সরাসরি সংরক্ষণ না করে সেই স্টেটে পৌঁছাতে ঘটা প্রতিটি ইভেন্টের সম্পূর্ণ ক্রমানুসারে সংরক্ষণ করা — বর্তমান স্টেট প্রয়োজনমতো সেই ইভেন্টগুলো replay করে গণনা করা হয়। এর বদলে প্রতিটি ঘটে যাওয়া ইভেন্ট ("deposit ৳100", "withdraw ৳30") ক্রমানুসারে চিরস্থায়ীভাবে সংরক্ষণ করে — বর্তমান ব্যালেন্স দরকার হলে সেই ইভেন্টগুলো শুরু থেকে "replay" (ভাঁজ করে/fold করে) করে বের করা হয়।

২ · CQRS — Write Model ও Read Model আলাদা করা

CQRSCQRS (Command Query Responsibility Segregation)একটি সিস্টেমের "লেখার পাথ" (কমান্ড, যা বিজনেস রুল যাচাই করে ইভেন্ট তৈরি করে) কে "পড়ার পাথ" (কোয়েরি, যা প্রায়ই ডিনরমালাইজড read model থেকে সরাসরি পড়ে) থেকে আলাদা করা। স্বীকার করে যে একটি অ্যাপ্লিকেশনের লেখা ও পড়ার চাহিদা প্রায়ই খুব ভিন্ন। Write model বিজনেস রুল যাচাই করে এবং নতুন ইভেন্ট অ্যাপেন্ড করে ("balance withdraw করার আগে যথেষ্ট টাকা আছে কিনা যাচাই করো")। Read model সাধারণত একটি ডিনরমালাইজড, প্রি-কম্পিউটেড ভিউ — যা দ্রুত পড়ার জন্য অপ্টিমাইজড, প্রায়ই ইভেন্ট থেকে একটি projection (প্রক্ষেপণ) হিসেবে তৈরি হয়।

দুটো মডেল আলাদা থাকায় প্রতিটিকে স্বাধীনভাবে স্কেল ও অপ্টিমাইজ করা যায় — লেখা কম হলেও পড়া অনেক বেশি হতে পারে (L02-এর read:write ratio ধারণার সাথে সংযোগ), তাই read model-কে আলাদাভাবে ক্যাশ (L19) বা রেপ্লিকেট (L16) করা যায়, write model-এর ওপর প্রভাব না ফেলেই।

৩ · Python দিয়ে ইভেন্ট-সোর্সড ব্যাংক অ্যাকাউন্ট

নিচের কোডে events নামে একটি লিস্টে সব ("deposit", amount)/("withdraw", amount) টাপল সংরক্ষিত হয়। replay(events) ফাংশনটি write-model-স্টাইলে পুরো ইতিহাস থেকে ব্যালেন্স গণনা করে, আর একটি আলাদা read_model ডিকশনারি CQRS-স্টাইলে প্রতিটি ইভেন্ট ঘটার সাথে সাথেই ইনক্রিমেন্টালি আপডেট হয়। শেষে দুটো পদ্ধতি একই ফলাফলে একমত হয় কিনা যাচাই করা হয়।

events = []
read_model = {"balance": 0}   # CQRS read model — প্রতিটি ইভেন্টে সাথে সাথে আপডেট হয়

def append_event(event_type, amount):
    events.append((event_type, amount))
    # read model ইনক্রিমেন্টালি আপডেট (projection)
    if event_type == "deposit":
        read_model["balance"] += amount
    elif event_type == "withdraw":
        read_model["balance"] -= amount

def replay(events_list):
    # write-model derivation — শুরু থেকে সব ইভেন্ট fold করে ব্যালেন্স বের করা
    balance = 0
    for event_type, amount in events_list:
        if event_type == "deposit":
            balance += amount
        elif event_type == "withdraw":
            balance -= amount
    return balance


append_event("deposit", 100)
append_event("deposit", 50)
append_event("withdraw", 30)
append_event("deposit", 20)
append_event("withdraw", 10)

print("সব ইভেন্ট:")
for e in events:
    print(" ", e)

replayed_balance = read_model_balance = None
replayed_balance = replay(events)
read_model_balance = read_model["balance"]

print()
print("replay() দিয়ে (write-model) ব্যালেন্স:", replayed_balance)
print("read_model (CQRS) ব্যালেন্স:          ", read_model_balance)
print("দুটো মিলছে কি?", replayed_balance == read_model_balance)

৪ · ট্রেড-অফ

Event Sourcing ও CQRS জটিলতা বাড়ায় — এখন দুটো মডেল রক্ষণাবেক্ষণ করতে হয়, এবং বাস্তব ডিস্ট্রিবিউটেড সিস্টেমে read model সাধারণত write model-এর তুলনায় সামান্য দেরিতে (eventual consistency, L04) আপডেট হয় — একটি লেখার ঠিক পরপরই read model-এ তা প্রতিফলিত নাও হতে পারে। বিনিময়ে সিস্টেম পায় সম্পূর্ণ audit log, ইতিহাসের যেকোনো মুহূর্তের স্টেট পুনর্গঠনের ক্ষমতা, এবং write/read পাথ স্বাধীনভাবে স্কেল করার সুবিধা — যা উচ্চ-স্কেল, অডিট-সংবেদনশীল সিস্টেমে (ব্যাংকিং, ইনভেন্টরি, অর্ডার প্রসেসিং) প্রায়ই এই বাড়তি জটিলতার মূল্য দেয়।