সেবা জুড়ে আপনি সাধারণত শক্তিশালী সামঞ্জস্যকে চূড়ান্ত সামঞ্জস্যের জন্য বিনিময় করেন, এবং সেটিকে ব্যবহারিক এবং সঠিক করার জন্য CQRS এবং event sourcing এর উপর নির্ভর করেন।
পরিবর্তনের পরে, প্রতিলিপিগুলি তাৎক্ষণিকভাবে নয় বরং "শীঘ্রই" একত্রিত হয়। বেশিরভাগ ব্যবসায়িক প্রবাহের জন্য গ্রহণযোগ্য (একটি ইনভেন্টরি গণনা এক সেকেন্ড বিলম্বিত হতে পারে), কিছুর জন্য অগ্রহণযোগ্য (একটি ব্যাংক শেষ অবস্থা পরীক্ষা)।
লেখা মডেলকে একটি বা একাধিক পড়া মডেল থেকে আলাদা করুন।
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
লেখার স্বাধীনভাবে পড়াগুলি স্কেল এবং পুনর্গঠিত হয়; পড়া মডেলটি ইভেন্ট থেকে আপডেট করা হয়, তাই এটি চূড়ান্তভাবে সামঞ্জস্যপূর্ণ।
ইভেন্টগুলির ক্রমকে সত্যের উৎস হিসাবে সংরক্ষণ করুন, শুধু বর্তমান অবস্থা নয়। বর্তমান অবস্থা ইভেন্টগুলির উপর একটি fold।
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| কৌশল | লাভ | খরচ |
|---|---|---|
| চূড়ান্ত সামঞ্জস্য | উপলব্ধতা, স্কেল | পুরানো পড়া, সংঘাত |
| CQRS | পড়া/লেখার স্কেল | দুটি মডেল সিঙ্ক রাখতে হবে |
| ইভেন্ট সোর্সিং | অডিট, রিপ্লে, ইতিহাস | স্কিমা/ইভেন্ট বিবর্তন, জটিলতা |
সর্বত্র event sourcing গ্রহণ করবেন না — এটি শক্তিশালী কিন্তু ভারী। এটি ব্যবহার করুন যেখানে অডিট/ইতিহাস সত্যিই গুরুত্বপূর্ণ।
বিতরণকৃত সিস্টেমগুলি একবারে শক্তিশালী সামঞ্জস্য, উপলব্ধতা এবং ভাগ সহনশীলতা সবই থাকতে পারে না, তাই সিনিয়র ডিজাইন সম্পর্কে যেখানে চূড়ান্ত সামঞ্জস্য গ্রহণযোগ্য তা বেছে নেওয়া।
CQRS এবং event sourcing আপনাকে চূড়ান্ত সামঞ্জস্যকে নির্ভরযোগ্য এবং নিরীক্ষণযোগ্য করার সরঞ্জাম দেয় — তবে প্রতিটি আসল জটিলতা যোগ করে, তাই সেগুলি সার্জিক্যালভাবে প্রয়োগ করুন, ডিফল্ট নয়।