কোলাবোরেটিভ এডিটর ডিজাইন

সমস্যাটি বোঝা

Google Docs-এর কথা চিন্তা করুন: অনেক মানুষ একই সময়ে একটি ডকুমেন্ট এডিট করছেন, সবাই একে অপরের কার্সরগুলো রিয়েল-টাইমে নড়াচড়া করতে দেখছেন। একজনের কাজের সাথে আরেকজনের কাজে কোনো ঝামেলা ছাড়াই এই জিনিসটা কীভাবে কাজ করে?

চলুন এর রিকয়ারমেন্টগুলো দেখে নেওয়া যাক:

ফাংশনাল রিকয়ারমেন্টস:

• ডকুমেন্ট তৈরি ও এডিট করা — বোল্ড, ইটালিক, হেডিংসহ রিচ টেক্সট এডিটিংয়ের সুবিধা থাকা।
• রিয়েল-টাইম কোলাবোরেশন বা একযোগে কাজ করা — অনেক ব্যবহারকারী একসাথে লেখালেখি করতে পারবেন এবং <১০০ মি.সে. এর মধ্যে সবার কাছে সেই আপডেট পৌঁছে যাবে।
• কার্সরের উপস্থিতি — কারা কোথায় টাইপ করছেন তা নাম ও রঙিন কার্সর দিয়ে দেখতে পারার ব্যবস্থা।
• ভার্সন হিস্টোরি — ডকুমেন্টের পুরোনো ভার্সন দেখা এবং সেখানে রিস্টোর করার অপশন।
• কমেন্টিং বা মন্তব্য করা — নির্দিষ্ট কোনো লেখা সিলেক্ট করে তার পাশে কমেন্ট করতে পারা।

নন-ফাংশনাল রিকয়ারমেন্টস:

• লো ল্যাটেন্সি সিঙ্ক: ইউজারদের কোনো ঝামেলা ছাড়াই কাজ করতে দেওয়ার জন্য <১০০ মি.সে. এর মধ্যে সবার কাছে সব চেঞ্জ আপডেট হয়ে যাওয়ার ব্যবস্থা থাকতে হবে।
• কনফ্লিক্ট-ফ্রি বা ঝামেলামুক্ত: যখন দুজন ব্যবহারকারী একই প্যারাগ্রাফে একই সময়ে এডিট করেন, এর রেজাল্টটি একদম সঠিক হতে হবে — কোনো অক্ষর বা লাইন যেন হারিয়ে না যায়।
• অফলাইন সাপোর্ট: ব্যবহারকারীরা অফলাইনে এডিট করতে পারবেন এবং যখন আবার ইন্টারনেটে যুক্ত হবেন তখন স্বয়ংক্রিয়ভাবে সিঙ্ক হয়ে যাবে।
• ইভেনচুয়াল কনসিস্টেন্সি: অপারেশন যেভাবেই হোক না কেন, সব ব্যবহারকারী শেষ পর্যন্ত একই ডকুমেন্ট স্টেট বা আউটপুট দেখতে পাবেন।

প্রাথমিক একটা হিসাব-নিকাশ

চলুন সিস্টেমটার বড়সড় একটা সাইজের হিসাব করি:

• প্ল্যাটফর্মে মোট ১০০ মিলিয়ন (১০ কোটি) ডকুমেন্ট আছে।
• পিক টাইমে ১০ মিলিয়ন (১ কোটি) একসাথে সম্পাদনা সেশন বা কনকারেন্ট এডিটিং সেশন চলছে।
• প্রতি ডকুমেন্টে গড়ে ৩ জন এডিটর কাজ করছেন — তার মানে প্রায় ৩০ মিলিয়ন কনকারেন্ট ওয়েব সকেট (WebSocket) কানেকশন তৈরি হচ্ছে।
• প্রতি মিনিটে ৫০ মিলিয়ন অপারেশন — প্রতিটি কিস্ট্রোক, কার্সরের নড়াচড়া বা ফরমেটিংয়ের কাজকে এক-একটি অপারেশন হিসেবে গোনা হচ্ছে।
• অপারেশন সাইজ: প্রতিটি অপারেশনের সাইজ ~১০০-২০০ বাইট (টাইপ + পজিশন + কন্টেন্ট + মেটাডেটা)।
• স্টোরেজ: প্রতিটি ডকুমেন্টে গড়ে ~৫০ KB টেক্সট + অপারেশনের হিস্টোরি থাকে। শুধুমাত্র ডকুমেন্টের জন্যই লাগবে ১০০ মিলিয়ন ডকস × ৫০ KB = ~৫ TB। অপারেশন লগগুলোর হিসেব ধরলে এই স্টোরেজের সাইজ আরও অনেক বড় হবে।

এখানে মূল চ্যালেঞ্জগুলো হলো: (১) সবার কনকারেন্ট অপারেশনগুলো একসাথে সঠিকভাবে মিলিয়ে দেওয়া, (২) এত বড় স্কেলে ওয়েব সকেট কানেকশনগুলো চালু রাখা, এবং (৩) খুব দক্ষতার সাথে অপারেশনের হিস্টোরি স্টোর এবং রিপ্লে করা।

কনফ্লিক্ট বা দ্বন্দ্ব মেটানো: OT বনাম CRDT

কোলাবোরেটিভ এডিটিংয়ে সবচেয়ে বড় টেকনিক্যাল চ্যালেঞ্জ হলো: যখন দুজন মানুষ একই জায়গায় একই সময়ে এডিট করবেন, তখন কী ঘটবে?

অপারেশনাল ট্রান্সফর্মেশন (OT)

• গুগল ডকস এই অ্যাপ্রোচ ব্যবহার করে। এর প্রতিটি এডিট বা কাজকে এক-একটি "অপারেশন" (ইনসার্ট, ডিলিট, ফরম্যাট) বলা হয়।
• সার্ভার যখন একযোগে অনেকগুলো অপারেশন পায়, তখন সবকিছুর পজিশন বা অবস্থান ঠিক রাখার জন্য এটি একটি অপারেশনের বিপরীতে আরেকটি অপারেশনকে ট্রান্সফর্ম বা বদল করে দেয়।
• কোন অপারেশনটি আগে হবে তা নির্ধারণ করার জন্য একটি সেন্ট্রাল সার্ভার লাগে।
• খুব বড় স্কেলে এই পদ্ধতি পরীক্ষিত কিন্তু সঠিকভাবে ইমপ্লিমেন্ট করা বেশ জটিল (ট্রান্সফর্মেশন ফাংশনের অনেক রকম এজ কেস বা এক্সেপশনাল পরিস্থিতি থাকে)।

কনফ্লিক্ট-ফ্রি রেপ্লিকেটেড ডেটা টাইপস (CRDTs)

• এটি একটি নতুন অ্যাপ্রোচ বা পদ্ধতি যেখানে সেন্ট্রাল সার্ভার ছাড়াই ডেটা স্ট্রাকচারটি নিজে নিজেই কনভার্জ বা সবাইকে এক জায়গায় মিলিয়ে দেওয়ার গ্যারান্টি দেয়।
• এর প্রতিটি ক্যারেক্টার বা অক্ষরের একটি ইউনিক, সিরিয়াল করা আইডি থাকে। অপারেশন যে অর্ডারেই হোক না কেন, ডেটা এখানে স্বয়ংক্রিয়ভাবেই মার্জ হয়ে যায়।
• এটি পিয়ার-টু-পিয়ার (P2P) সিস্টেম এবং অফলাইন এডিটিংয়ের জন্য দারুণ কাজ করে।
• তবে এর মেমোরি ওভারহেড বেশি (কারণ প্রতিটি অক্ষরের সাথেই মেটাডেটা যুক্ত থাকে), তবে কনফ্লিক্ট বা দ্বন্দ্বের লজিকটি এখানে তুলনামূলকভাবে বেশ সহজ।

বাস্তব জগতে: সার্ভার-সেন্ট্রিক আর্কিটেকচারগুলোতে (যেমন Google Docs, Etherpad) OT-ই সবচেয়ে বেশি পরীক্ষিত। আর অফলাইন-ফার্স্ট এবং P2P অ্যাপগুলোর (Figma একটি CRDT-মতো পদ্ধতি ব্যবহার করে) ক্ষেত্রে CRDTs দ্রুত জনপ্রিয়তা পাচ্ছে।

OT সম্পর্কে বিস্তারিত

OT-এর প্রাণভোমরা হলো transform(op1, op2) ফাংশন। যখন একই ডকুমেন্টে একটি নির্দিষ্ট সময়ে দুটি অপারেশন একসাথে করা হয়, এই ফাংশনটি তাদের পজিশন এমনভাবে অ্যাডজাস্ট করে দেয় যাতে একটির পর একটি অপারেশন সিকুয়েন্সে প্রয়োগ করা যায়।

একটি ক্লাসিক উদাহরণ দেখা যাক:

• ডকুমেন্টের বর্তমান অবস্থা: "ABCDEFGH"
• ইউজার A: ৫ নম্বর পজিশনে "Hello" যোগ (insert) করেছেন → "ABCDEHelloFGH"
• ইউজার B: ৩ নম্বর পজিশনে একটি অক্ষর ("D") মুছে ফেলেছেন (delete) → "ABCEFGH"
• این কাজগুলো একই সাথে (কনকারেন্টলি) হচ্ছে — কেউ কারও কাজ দেখতে পাচ্ছেন না।

সার্ভার যেভাবে ট্রান্সফর্ম করে:

• B ৩ নম্বর পজিশনের অক্ষরটি ডিলিট করেছেন, যা A-এর ৫ নম্বর পজিশনের ইনসার্টের আগে।
• তাই A-এর ইনসার্টের অবস্থান বাম দিকে ১ ঘর সরে আসবে: পজিশন ৫ → পজিশন ৪।
• দুটো অপারেশন করার পর ফলাফল দাঁড়ালো: "ABCEHelloFGH" — এভাবে সবার কাছেই ডেটা কনভার্জ হয়।

যখন অনেকগুলো কাজের রেঞ্জ ওভারল্যাপ করে, একাধিক ইউজার কনকারেন্টলি টাইপ করেন, এবং প্রচুর রিচ টেক্সট ফরমেটিং থাকে, তখন এই ট্রান্সফর্মেশনের নিয়মগুলো বেশ জটিল হয়ে যায়। তবে এর মূল ধারণাটা সবসময় একই থাকে: আপনার আগে অন্যেরা কী অপারেশন করেছে তার ওপর ভিত্তি করে আপনার পজিশন অ্যাডজাস্ট করা।

সাপোর্টিং ফিচারসমূহ

কার্সরের উপস্থিতি:

• প্রতিটি ক্লায়েন্ট তাদের কার্সরের পজিশনের আপডেটগুলো একটি ওয়েব সকেট (WebSocket) কানেকশনের মাধ্যমে (প্রায় ১০টি আপডেট/সেকেন্ড এই রেটে থ্রটল করে) পাঠায়।
• সার্ভার এই কার্সরের পজিশনগুলো ডকুমেন্টে থাকা সব কোলাবোরেটরদের ব্রডকাস্ট করে জানিয়ে দেয়।
• টেক্সট অপারেশনের সাথে সাথেই কার্সরের পজিশনগুলোও ট্রান্সফর্ম হয়ে যায় — যদি কেউ আপনার কার্সরের আগে কোনো টেক্সট যোগ করেন, তবে আপনার কার্সরটি ডান পাশে সরে যাবে।

কমেন্টিং বা মন্তব্য করা:

• টেক্সটের নির্দিষ্ট কোনো রেঞ্জ বা অংশগুলোতে (স্টার্টিং পজিশন, এন্ডিং পজিশন) হাইলাইট করে কমেন্টগুলো রাখা হয়।
• যখন সেই কমেন্টের আশেপাশে কোনো লেখা এডিট করা হয়, একই OT লজিক ব্যবহার করে কমেন্টের অবস্থানগুলোও ট্রান্সফর্ম করে দেওয়া হয়।
• ডকুমেন্টের কন্টেন্ট আর কমেন্টগুলো আলাদাভাবে সংরক্ষণ করা হয়, কিন্তু রেঞ্জ মার্কারগুলোর মাধ্যমে তারা একে অপরের সাথে যুক্ত থাকে।

ভার্সন হিস্টোরি:

• পর্যায়ক্রমে পুরো ডকুমেন্টের একটি স্ন্যাপশট (প্রতি N সংখ্যক অপারেশনের পরে অথবা প্রতি M মিনিট পরপর) নেওয়া হয়।
• দুটি স্ন্যাপশটের মাঝখানে অপারেশনের লগগুলো (অ্যাপেন্ড-অনলি পদ্ধতিতে) সেভ করে রাখা হয়।
• আগের একটি ভার্সন রিস্টোর করার জন্য: সবচেয়ে কাছের স্ন্যাপশটটি লোড করে তারপর অপারেশন লগগুলো একটার পর একটা রিপ্লে বা রি-রান করা হয়।
• ডাটাবেসগুলো WAL (রাইট-অ্যাহেড লগ) + চেকপয়েন্ট দিয়ে যেভাবে কাজ করে, এটিও ঠিক একই নিয়মে কাজ করে।

পারমিশন:

• ডকুমেন্ট লেভেলের অ্যাক্সেসগুলো এ রকম হতে পারে: ওনার (owner), এডিটর (editor), কমেন্টার (commenter) এবং ভিউয়ার (viewer)।
• প্রতিবার ওয়েব সকেট কানেকশন তৈরি হওয়ার সময় এবং যেকোনো অপারেশন রিসিভ করার সময় এই পারমিশনগুলো চেক করা হয়।
• রিয়েল-টাইমে পারমিশনে কোনো চেঞ্জ আসলে সাথে সাথেই ক্লায়েন্টকে ডিসকানেক্ট/রিকানেক্ট করে দেওয়া হয়।