CQRS: read আর write আলাদা করা
CQRS data বদলানোর মডেল আর পড়ার মডেল আলাদা করে। এটি scale ও জটিলতার সমস্যা মেটাতে পারে, আবার অনেক সমস্যা যোগও করে।
CQRS মানে Command Query Responsibility Segregation। ধারণা: data বদলাতে (command) একটি মডেল আর পড়তে (query) আরেকটি আলাদা মডেল ব্যবহার করা।
কোন সমস্যা মেটায়
দুটোর জন্য একটি মডেল প্রায়ই আপসের হয়ে ওঠে। Write চায় পরিষ্কার, normalised গঠন ও কড়া নিয়ম। Read চায় screen-এর মতো সাজানো data: join করা, ফিল্টার করা, সারাংশ এবং দ্রুত। অ্যাপ বড় হলে একই table-এ দুটো চাপাতে গিয়ে ধীর query আর জট পাকানো কোড তৈরি হয়।
কীভাবে কাজ করে
- Command দিক:
PlaceOrder-এর মতো কাজ সামলায়। business নিয়ম যাচাই করে write store-এ লেখে। - Query দিক: screen বা API-র মাপে সাজানো read model থেকে read সার্ভ করে (যেমন denormalised "order summary" table, search index বা cache)।
- Synchronisation: write-এর পর পরিবর্তন (প্রায়ই queue দিয়ে event হিসেবে) read model আপডেট করে।
খরচ: eventual consistency
Read model write-এর একটু পরে আপডেট হয়, তাই user মুহূর্তের জন্য নিজের পরিবর্তন নাও দেখতে পারে। সামলান: write-এর ঠিক পরে write দিক থেকে পড়ে, UI-তে আশাবাদীভাবে পরিবর্তন দেখিয়ে, বা অল্প দেরি মেনে নিয়ে।
CQRS-এর স্তর
- সহজ: একই database, command ও query-র জন্য আলাদা কোডের পথ ও মডেল। সস্তা এবং প্রায়ই যথেষ্ট।
- আলাদা read store: একই data read-এর জন্য tune করা store-এ কপি।
- পূর্ণ: আলাদা database, event-ভিত্তিক sync, প্রায়ই event sourcing-এর সাথে।
কখন মানায়
- Read-এর volume ও আকার write থেকে অনেক আলাদা।
- Write-এ জটিল domain নিয়ম, read-এ dashboard বা search।
- Read ও write আলাদাভাবে scale করতে হবে।
কখন বাড়াবাড়ি
সাধারণ CRUD অ্যাপ। বাড়তি অংশ, sync bug ও পুরোনো read-এর দাম পোষায় না। স্তর ১ দিয়ে শুরু করুন, দরকার হলে তবেই ওপরে উঠুন।
মূল কথা: CQRS read/write অমিলের টুল। আলাদা কোডের পথ দিয়ে শুরু করুন, সংখ্যা চাইলে তবেই আলাদা read store যোগ করুন।
System Design সিরিজ, পর্ব ২ (building block): 12 নম্বর (মোট 14)। আগের লেখা: Service discovery: service-রা কীভাবে একে অপরকে খোঁজে.
