ধাপ ৩ - ডিজাইনের গভীর বিশ্লেষণ (Design deep dive)

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

সার্ভিস ডিসকভারি (Service discovery)

সার্ভিস ডিসকভারির প্রাথমিক ভূমিকা হলো ভৌগলিক অবস্থান, সার্ভারের ক্ষমতা ইত্যাদি মাপদণ্ডের ওপর ভিত্তি করে ক্লায়েন্টের জন্য সেরা চ্যাট সার্ভার সুপারিশ করা। Apache Zookeeper [7] সার্ভিস ডিসকভারির জন্য একটি জনপ্রিয় ওপেন-সোর্স সমাধান। এটি সমস্ত উপলব্ধ চ্যাট সার্ভার নিবন্ধন করে এবং পূর্বনির্ধারিত মাপদণ্ডের ওপর ভিত্তি করে ক্লায়েন্টের জন্য সেরা চ্যাট সার্ভার বাছাই করে।

চিত্র ১১ দেখায় কীভাবে সার্ভিস ডিসকভারি (Zookeeper) কাজ করে।

[চিত্র ১১-এর বর্ণনা: ছবিটি একটি সিস্টেম আর্কিটেকচার ডায়াগ্রাম যা একজন ব্যবহারকারীর লগইন এবং পরবর্তীতে চ্যাট সার্ভিসে সংযোগের প্রবাহ চিত্রিত করে। ইউজার A, একটি স্মার্টফোন আইকন দ্বারা উপস্থাপিত, একটি লগইন (‘১. login’ লেবেলযুক্ত) রিকোয়েস্ট শুরু করে যা একটি লোড ব্যালেন্সারের দিকে নির্দেশিত। লোড ব্যালেন্সার (‘লোড ব্যালেন্সার’ লেবেলযুক্ত) তারপর রিকোয়েস্টটি API সার্ভারের (‘API সার্ভার’ লেবেলযুক্ত) একটি সেটে ফরওয়ার্ড করে। এই API সার্ভারগুলো, তাদের পালায়, একটি উপলব্ধ চ্যাট সার্ভার খুঁজে পেতে একটি সার্ভিস ডিসকভারি সিস্টেম, বিশেষ করে Zookeeper (‘সার্ভিস ডিসকভারি (Zookeeper)’ লেবেলযুক্ত)-এর সাথে মিথস্ক্রিয়া করে। Zookeeper একাধিক চ্যাট সার্ভার দেখায় (উল্লম্ব আয়তক্ষেত্র দ্বারা উপস্থাপিত যার লেবেল ‘চ্যাট সার্ভার ১’, ‘চ্যাট সার্ভার ২’, এবং ‘চ্যাট সার্ভার N’)। API সার্ভারগুলো Zookeeper-এর মাধ্যমে একটি উপলব্ধ চ্যাট সার্ভার খুঁজে পাওয়ার পরে, ব্যবহারকারী একটি নির্দিষ্ট চ্যাট সার্ভারে একটি ওয়েবসকেট সংযোগ (‘৪. ws’ লেবেলযুক্ত) স্থাপন করে, যা ‘চ্যাট সার্ভার ২’-এর দিকে নির্দেশিত তীর চিহ্ন দ্বারা নির্দেশিত। ১, ২, ৩, এবং ৪ সংখ্যাগুলো প্রক্রিয়ার ক্রমিক ধাপগুলিকে উপস্থাপন করে।] চিত্র ১১ ১. ইউজার A অ্যাপে লগ ইন করার চেষ্টা করে। ২. লোড ব্যালেন্সার লগইন রিকোয়েস্টটি API সার্ভারে পাঠায়। ৩. ব্যাকএন্ড ব্যবহারকারীকে প্রমাণীকরণ (authenticate) করার পরে, সার্ভিস ডিসকভারি ইউজার A-এর জন্য সেরা চ্যাট সার্ভার খুঁজে পায়। এই উদাহরণে, সার্ভার ২ কে বেছে নেওয়া হয়েছে এবং সার্ভারের তথ্যটি ইউজার A-এর কাছে ফেরত পাঠানো হয়। ৪. ইউজার A ওয়েবসকেটের মাধ্যমে চ্যাট সার্ভার ২-এর সাথে সংযোগ স্থাপন করে।

মেসেজ ফ্লো (Message flows)

একটি চ্যাট সিস্টেমের এন্ড-টু-এন্ড ফ্লো বোঝা আকর্ষণীয়। এই বিভাগে, আমরা ১-এর-সাথে-১ চ্যাট ফ্লো, একাধিক ডিভাইস জুড়ে মেসেজ সিঙ্ক্রোনাইজেশন এবং গ্রুপ চ্যাট ফ্লো অন্বেষণ করব।

১-এর-সাথে-১ চ্যাট ফ্লো

চিত্র ১২ ব্যাখ্যা করে যখন ইউজার A ইউজার B-কে একটি মেসেজ পাঠায় তখন কী ঘটে।

[চিত্র ১২-এর বর্ণনা: ছবিটি একটি সরলীকৃত চ্যাট অ্যাপ্লিকেশন আর্কিটেকচার উপস্থাপন করে। দুইজন ব্যবহারকারী, ইউজার A এবং ইউজার B, স্মার্টফোন আইকন দ্বারা উপস্থাপিত, সিস্টেমের সাথে মিথস্ক্রিয়া করে। ইউজার A (১) চ্যাট সার্ভার ১-এ একটি মেসেজ পাঠায়, যা একটি বেগুনি ডাটাবেস আইকন। চ্যাট সার্ভার ১ (২) আইডি জেনারেটরের কাছ থেকে একটি অনন্য মেসেজ আইডির অনুরোধ করে (সবুজ ডাটাবেস ক্লাস্টার আইকন)। আইডি পাওয়ার পরে, চ্যাট সার্ভার ১ (৩) মেসেজটিকে একটি মেসেজ সিঙ্ক কিউ-তে পুশ করে (তিনটি খাম আইকন)। মেসেজ সিঙ্ক কিউ একটি বাফার হিসাবে কাজ করে, অন্য উপাদানগুলোতে মেসেজ বিতরণ করে। কিউ (৪) স্থায়ী সংরক্ষণের জন্য মেসেজটি KV স্টোরে (নীল ডাটাবেস ক্লাস্টার আইকন) পাঠায়। ইউজার B (৬) চ্যাট সার্ভার ২-এর (অন্য একটি বেগুনি ডাটাবেস আইকন) সাথে সংযুক্ত। চ্যাট সার্ভার ২ মেসেজ সিঙ্ক কিউ থেকে দুটি পথের মাধ্যমে মেসেজ গ্রহণ করে: তাৎক্ষণিক ডেলিভারির জন্য ৫.a (অনলাইন) এবং অফলাইন মেসেজ সংরক্ষণ এবং ডেলিভারির জন্য PN সার্ভার (সবুজ ডাটাবেস ক্লাস্টার আইকন) ব্যবহার করে ৫.b (অফলাইন)। সংখ্যায়িত তীর চিহ্নগুলো উপাদানগুলোর মধ্যে তথ্যের প্রবাহ নির্দেশ করে।] চিত্র ১২ ১. ইউজার A চ্যাট সার্ভার ১-এ একটি চ্যাট মেসেজ পাঠায়। ২. চ্যাট সার্ভার ১ আইডি জেনারেটরের কাছ থেকে একটি মেসেজ আইডি পায়। ৩. চ্যাট সার্ভার ১ মেসেজটি মেসেজ সিঙ্ক কিউ-তে পাঠায়। ৪. মেসেজটি একটি কী-ভ্যালু স্টোরে সংরক্ষণ করা হয়। ৫.a. যদি ইউজার B অনলাইনে থাকে, তবে মেসেজটি চ্যাট সার্ভার ২-তে ফরওয়ার্ড করা হয় যেখানে ইউজার B সংযুক্ত আছে। ৫.b. যদি ইউজার B অফলাইনে থাকে, তবে পুশ নোটিফিকেশন (PN) সার্ভার থেকে একটি পুশ নোটিফিকেশন পাঠানো হয়। ৬. চ্যাট সার্ভার ২ মেসেজটি ইউজার B-তে ফরওয়ার্ড করে। ইউজার B এবং চ্যাট সার্ভার ২-এর মধ্যে একটি স্থায়ী ওয়েবসকেট সংযোগ রয়েছে।

একাধিক ডিভাইসের মধ্যে মেসেজ সিঙ্ক্রোনাইজেশন

অনেক ব্যবহারকারীর একাধিক ডিভাইস থাকে। আমরা ব্যাখ্যা করব কীভাবে একাধিক ডিভাইস জুড়ে মেসেজ সিঙ্ক করতে হয়। চিত্র ১৩ মেসেজ সিঙ্ক্রোনাইজেশনের একটি উদাহরণ দেখায়।

[চিত্র ১৩-এর বর্ণনা: ছবিটি একজন ব্যবহারকারীর (ইউজার A) জন্য একটি চ্যাট অ্যাপ্লিকেশনের ডেটা ফ্লোর একটি সরলীকৃত আর্কিটেকচার ডায়াগ্রাম উপস্থাপন করে। দুটি ক্লায়েন্ট ডিভাইস, ইউজার A-এর ফোন এবং ইউজার A-এর ল্যাপটপ, পৃথক বাক্স হিসাবে চিত্রিত, প্রতিটি তাদের বর্তমান সর্বোচ্চ মেসেজ আইডি প্রদর্শন করে (ফোনের জন্য ৬৫৩ এবং ল্যাপটপের জন্য ৮৪২)। এই ডিভাইসগুলো একটি কেন্দ্রীয় ‘চ্যাট সার্ভার ১’-এর সাথে যোগাযোগ করে, যা একটি বেগুনি আয়তক্ষেত্র হিসাবে উপস্থাপিত। চ্যাট সার্ভার ১ বাক্সের ভেতরে, ‘ইউজার A-এর ফোনের জন্য সেশন’ এবং ‘ইউজার A-এর ল্যাপটপের জন্য সেশন’ প্রতিটি ডিভাইসের জন্য পৃথক সেশন নির্দেশ করে। তীর চিহ্নগুলো প্রতিটি ডিভাইস থেকে চ্যাট সার্ভারে একমুখী ডেটা প্রবাহ দেখায়। পরিশেষে, চ্যাট সার্ভার একটি ‘KV স্টোর’-এর সাথে মিথস্ক্রিয়া করে (সম্ভবত একটি কী-ভ্যালু ডাটাবেস) যা তিনটি স্তূপকৃত নীল সিলিন্ডার দ্বারা উপস্থাপিত, যা নির্দেশ করে যে মেসেজ ডেটা স্থায়ীভাবে সংরক্ষিত হয়। তীর চিহ্নগুলো চিত্রিত করে যে ফোন এবং ল্যাপটপ উভয় সেশন চ্যাট সার্ভারের মাধ্যমে KV স্টোরে ডেটা পাঠায়।] চিত্র ১৩ চিত্র ১৩-এ, ইউজার A-এর দুটি ডিভাইস রয়েছে: একটি ফোন এবং একটি ল্যাপটপ। যখন ইউজার A তার ফোন দিয়ে চ্যাট অ্যাপে লগ ইন করে, তখন এটি চ্যাট সার্ভার ১-এর সাথে একটি ওয়েবসকেট সংযোগ স্থাপন করে। একইভাবে, ল্যাপটপ এবং চ্যাট সার্ভার ১-এর মধ্যে একটি সংযোগ থাকে।

প্রতিটি ডিভাইস cur_max_message_id নামের একটি ভেরিয়েবল বজায় রাখে, যা ডিভাইসের সর্বশেষ মেসেজ আইডি ট্র্যাক করে। নিচের দুটি শর্ত পূরণ করে এমন মেসেজগুলোকে নতুন মেসেজ হিসাবে বিবেচনা করা হয়:

• প্রাপক আইডি বর্তমানে লগ-ইন করা ইউজার আইডির সমান।
• কী-ভ্যালু স্টোরে মেসেজ আইডি cur_max_message_id-এর চেয়ে বড়।

প্রতিটি ডিভাইসে পৃথক cur_max_message_id থাকায়, মেসেজ সিঙ্ক্রোনাইজেশন সহজ হয় কারণ প্রতিটি ডিভাইস KV স্টোর থেকে নতুন মেসেজ পেতে পারে।

ছোট গ্রুপ চ্যাট ফ্লো

এক-এর-সাথে-এক চ্যাটের তুলনায়, গ্রুপ চ্যাটের যুক্তি বেশি জটিল। চিত্র ১২-১৪ এবং ১২-১৫ ফ্লোটি ব্যাখ্যা করে।

[চিত্র ১৪-এর বর্ণনা: ছবিটি একটি সরলীকৃত চ্যাট অ্যাপ্লিকেশন আর্কিটেকচার উপস্থাপন করে। একজন ব্যবহারকারী, যার লেবেল ‘ইউজার A’, ‘চ্যাট সার্ভার ১’-এ একটি মেসেজ পাঠায়, যা একটি বেগুনি আয়তক্ষেত্র হিসাবে চিত্রিত। এই সার্ভারটি তারপর মেসেজটিকে দুটি পৃথক ‘মেসেজ সিঙ্ক কিউ’-তে পুশ করে, প্রতিটি একটি সায়ান আয়তক্ষেত্র হিসাবে উপস্থাপিত যার ভেতরে তিনটি খাম আইকন রয়েছে। এই কিউগুলো মধ্যস্থতাকারী হিসাবে কাজ করে, অন্য ব্যবহারকারীদের কাছে মেসেজ বিতরণ করে। একটি কিউ মেসেজটি ‘ইউজার B’-তে পাঠায়, এবং অন্য কিউ ‘ইউজার C’-তে পাঠায়, উভয়ই স্মার্টফোন আইকন দ্বারা উপস্থাপিত। পুরো সিস্টেমটি একটি মেসেজ-পাসিং আর্কিটেকচার চিত্রিত করে যেখানে একটি কেন্দ্রীয় সার্ভার অ্যাসিঙ্ক্রোনাস মেসেজ কিউ-এর মাধ্যমে একাধিক ক্লায়েন্টে মেসেজ বিতরণ পরিচালনা করে, নিশ্চিত করে যে মেসেজগুলো তাদের উদ্দিষ্ট প্রাপকদের কাছে পৌঁছায় এমনকি যদি তারা সক্রিয়ভাবে সংযুক্ত না থাকে।] চিত্র ১৪ চিত্র ১৪ ব্যাখ্যা করে যখন ইউজার A একটি গ্রুপ চ্যাটে একটি মেসেজ পাঠায় তখন কী ঘটে। ধরে নিন গ্রুপে ৩ জন সদস্য আছে (ইউজার A, ইউজার B এবং ইউজার C)। প্রথমে, ইউজার A-এর মেসেজটি প্রতিটি গ্রুপ সদস্যের মেসেজ সিঙ্ক কিউ-তে কপি করা হয়: একটি ইউজার B-এর জন্য এবং দ্বিতীয়টি ইউজার C-এর জন্য। আপনি মেসেজ সিঙ্ক কিউ-কে প্রাপকের একটি ইনবক্স হিসাবে ভাবতে পারেন। এই ডিজাইনের পছন্দটি ছোট গ্রুপ চ্যাটের জন্য ভালো কারণ:

• এটি মেসেজ সিঙ্ক ফ্লোকে সরল করে কারণ প্রতিটি ক্লায়েন্টের নতুন মেসেজ পেতে তার নিজের ইনবক্স চেক করা ছাড়া অন্য কিছুর প্রয়োজন হয় না।
• যখন গ্রুপের সংখ্যা ছোট হয়, তখন প্রতিটি প্রাপকের ইনবক্সে একটি কপি সংরক্ষণ করা খুব বেশি ব্যয়বহুল নয়।

WeChat একটি অনুরূপ পদ্ধতি ব্যবহার করে, এবং এটি একটি গ্রুপকে ৫০০ জন সদস্যের মধ্যে সীমাবদ্ধ রাখে [8]। তবে, অনেক ব্যবহারকারী আছে এমন গ্রুপের জন্য, প্রতিটি সদস্যের জন্য একটি মেসেজ কপি সংরক্ষণ করা গ্রহণযোগ্য নয়।

প্রাপক পক্ষে, একজন প্রাপক একাধিক ব্যবহারকারীর কাছ থেকে মেসেজ পেতে পারেন। প্রতিটি প্রাপকের একটি ইনবক্স (মেসেজ সিঙ্ক কিউ) থাকে যা বিভিন্ন প্রেরকের মেসেজ ধারণ করে। চিত্র ১৫ ডিজাইনটি চিত্রিত করে।

[চিত্র ১৫-এর বর্ণনা: ছবিটি একটি সরলীকৃত চ্যাট অ্যাপ্লিকেশন আর্কিটেকচার উপস্থাপন করে। দুইজন ব্যবহারকারী, ইউজার A এবং ইউজার B, স্মার্টফোন আইকন দ্বারা উপস্থাপিত, প্রতিটি একটি পৃথক চ্যাট সার্ভারের (যথাক্রমে চ্যাট সার্ভার ১ এবং চ্যাট সার্ভার ২, বেগুনি সার্ভার আইকন দ্বারা চিত্রিত) সাথে সংযুক্ত। এই চ্যাট সার্ভারগুলো, তাদের পালায়, একটি কেন্দ্রীয় ‘মেসেজ সিঙ্ক কিউ’-এর (সায়ান-রঙের বাক্সের ভেতরে তিনটি খাম আইকন দ্বারা উপস্থাপিত) সাথে সংযুক্ত, যা একটি মেসেজ ব্রোকার হিসাবে কাজ করে। মেসেজ কিউ তারপর মেসেজগুলো ইউজার C-তে (অন্য একটি স্মার্টফোন আইকন) ফরওয়ার্ড করে, যা একটি পরিস্থিতি নির্দেশ করে যেখানে ইউজার C ইউজার A এবং ইউজার B উভয়ের কাছ থেকে মেসেজ গ্রহণ করছে। তীর চিহ্নগুলো মেসেজ প্রবাহের দিক নির্দেশ করে, দেখায় যে ইউজার A এবং ইউজার B-এর কাছ থেকে মেসেজ তাদের respective চ্যাট সার্ভারে পাঠানো হয়, তারপর একত্রিত করা হয় এবং মেসেজ সিঙ্ক কিউ-এর মাধ্যমে ইউজার C-তে ফরওয়ার্ড করা হয়। সিস্টেমটি স্কেলেবিলিটির জন্য একটি বিতরণ করা আর্কিটেকচার ব্যবহার করে এবং সম্ভবত চ্যাট কার্যকারিতার বিভিন্ন দিক পরিচালনা করার জন্য পৃথক চ্যাট সার্ভার থাকে।] চিত্র ১৫

অনলাইন উপস্থিতি (Online presence)

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

উচ্চ-স্তরের ডিজাইনে, প্রেজেন্স সার্ভারগুলো অনলাইন স্ট্যাটাস পরিচালনা করার এবং ওয়েবসকেটের মাধ্যমে ক্লায়েন্টদের সাথে যোগাযোগ করার জন্য দায়ী। এমন কিছু ফ্লো রয়েছে যা অনলাইন স্ট্যাটাস পরিবর্তনকে ট্রিগার করবে। আসুন তাদের প্রতিটি পরীক্ষা করি।

ইউজার লগইন

ইউজার লগইন ফ্লো “সার্ভিস ডিসকভারি” বিভাগে ব্যাখ্যা করা হয়েছে। ক্লায়েন্ট এবং রিয়েল-টাইম সার্ভিসের মধ্যে একটি ওয়েবসকেট সংযোগ তৈরি হওয়ার পরে, ইউজার A-এর অনলাইন স্ট্যাটাস এবং last_active_at টাইমস্ট্যাম্প KV স্টোরে সংরক্ষণ করা হয়। লগ ইন করার পরে প্রেজেন্স ইন্ডিকেটর দেখায় যে ব্যবহারকারী অনলাইনে আছেন।

[চিত্র ১৬-এর বর্ণনা: ছবিটি ইউজার উপস্থিতি ট্র্যাক করার জন্য একটি সরলীকৃত সিস্টেম আর্কিটেকচার উপস্থাপন করে। ‘ইউজার A’ নির্দেশকারী একটি মোবাইল ডিভাইস ‘প্রেজেন্স সার্ভার’-এর একটি সেটের সাথে একটি ‘ws সংযোগ’ (সম্ভবত একটি ওয়েবসকেট সংযোগ) স্থাপন করে। এই সার্ভারগুলো ইউজার স্ট্যাটাস তথ্য পরিচালনা এবং আপডেট করার জন্য দায়ী। প্রেজেন্স সার্ভারগুলো, তাদের পালায়, এই তথ্য একটি ‘KV স্টোর’-এ (একটি কী-ভ্যালু স্টোর ডাটাবেস) সংরক্ষণ করে, যা তিনটি ডাটাবেস সিলিন্ডার দ্বারা চিত্রিত। KV স্টোরে ইউজার A-এর জন্য সংরক্ষিত ডেটা একটি JSON-এর মতো কাঠামো হিসাবে দেখানো হয়েছে: {status: online, last_active_at: timestamp}, যা ব্যবহারকারীর অনলাইন স্ট্যাটাস এবং শেষবার তারা সক্রিয় ছিলেন তার সময়কাল নির্দেশ করে। তীর চিহ্নগুলো তথ্যের একমুখী প্রবাহ চিত্রিত করে: ইউজার A থেকে প্রেজেন্স সার্ভারে এবং তারপর KV স্টোরে।] চিত্র ১৬

ইউজার লগআউট

যখন একজন ব্যবহারকারী লগ আউট করেন, তখন তিনি চিত্র ১৭-এ দেখানো ইউজার লগআউট ফ্লো-এর মধ্য দিয়ে যান। KV স্টোরে অনলাইন স্ট্যাটাস অফলাইনে পরিবর্তন করা হয়। প্রেজেন্স ইন্ডিকেটর দেখায় যে একজন ব্যবহারকারী অফলাইনে আছেন।

[চিত্র ১৭-এর বর্ণনা: ছবিটি একটি ইউজার লগআউট প্রক্রিয়া চিত্রিত করে এমন একটি সিস্টেম আর্কিটেকচার ডায়াগ্রাম উপস্থাপন করে। ডায়াগ্রামটি বাম-থেকে-ডানে প্রবাহ দেখায়। একদম বামে, ‘ইউজার A’ লেবেলযুক্ত একটি আয়তক্ষেত্রাকার বাক্সে একটি স্মার্টফোন নির্দেশকারী একটি আইকন রয়েছে, যা একটি মোবাইল ব্যবহারকারী নির্দেশ করে। ‘logout’ লেবেলযুক্ত একটি নীল তীর চিহ্ন ইউজার A থেকে একটি ড্যাশ করা নীল বাক্সে ঘেরা তিনটি উল্লম্বভাবে স্তূপকৃত সবুজ আয়তক্ষেত্রের ক্লাস্টারের দিকে প্রসারিত যা ‘API সার্ভার’ লেবেলযুক্ত। এটি নির্দেশ করে যে লগআউট রিকোয়েস্টটি ইউজার A-এর ডিভাইস থেকে উৎপন্ন হয় এবং API সার্ভারে পাঠানো হয়। API সার্ভার থেকে, আরেকটি নীল তীর চিহ্ন ‘প্রেজেন্স সার্ভার’ লেবেলযুক্ত একটি আয়তক্ষেত্রাকার বাক্সের দিকে নিয়ে যায়, যা ইউজার উপস্থিতির তথ্য পরিচালনার জন্য দায়ী উপাদানকে উপস্থাপন করে। পরিশেষে, একটি নীল তীর চিহ্ন ‘প্রেজেন্স সার্ভার’-কে ‘KV স্টোর’ লেবেলযুক্ত একটি আয়তক্ষেত্রাকার বাক্সের সাথে সংযুক্ত করে যাতে তিনটি নীল সিলিন্ডারের একটি আইকন রয়েছে, যা একটি কী-ভ্যালু স্টোর ডাটাবেসকে প্রতীকী করে। চূড়ান্ত লেবেল, ‘ইউজার A: {status:offline},’ নির্দেশ করে যে লগআউট প্রক্রিয়া সম্পূর্ণ হওয়ার পরে, KV স্টোরে ব্যবহারকারীর স্ট্যাটাস ‘offline’-এ আপডেট করা হয়। সামগ্রিক প্রবাহটি ইউজার A লগ আউট করার সময় ঘটনাগুলোর ক্রম চিত্রিত করে, সিস্টেমের ডাটাবেসে তাদের উপস্থিতির স্ট্যাটাস আপডেট করে।] চিত্র ১৭

ইউজার ডিসকানেকশন (সংযোগ বিচ্ছিন্ন হওয়া)

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

আমরা এই সমস্যা সমাধানের জন্য একটি হার্টবিট মেকানিজম (heartbeat mechanism) প্রবর্তন করি। পর্যায়ক্রমে, একটি অনলাইন ক্লায়েন্ট প্রেজেন্স সার্ভারে একটি হার্টবিট ইভেন্ট পাঠায়। যদি প্রেজেন্স সার্ভার একটি নির্দিষ্ট সময়ের মধ্যে, ধরা যাক x সেকেন্ডের মধ্যে ক্লায়েন্টের কাছ থেকে একটি হার্টবিট ইভেন্ট পায়, তবে একজন ব্যবহারকারীকে অনলাইন হিসাবে বিবেচনা করা হয়। অন্যথায়, তিনি অফলাইন।

চিত্র ১৮-এ, ক্লায়েন্ট প্রতি ৫ সেকেন্ডে সার্ভারে একটি হার্টবিট ইভেন্ট পাঠায়। ৩টি হার্টবিট ইভেন্ট পাঠানোর পরে, ক্লায়েন্টটি ডিসকানেক্টেড হয়ে যায় এবং x = ৩০ সেকেন্ডের মধ্যে রিকানেক্ট করে না (এই সংখ্যাটি যুক্তিটি প্রদর্শন করার জন্য স্বেচ্ছাচারীভাবে বেছে নেওয়া হয়েছে)। অনলাইন স্ট্যাটাস অফলাইনে পরিবর্তন করা হয়।

[চিত্র ১৮-এর বর্ণনা: ছবিটি একটি ক্লায়েন্ট-সার্ভার হার্টবিট মেকানিজম চিত্রিত করে এমন একটি সিকোয়েন্স ডায়াগ্রাম উপস্থাপন করে। ‘ক্লায়েন্ট’ এবং ‘সার্ভার’ লেবেলযুক্ত দুটি আয়তক্ষেত্রাকার বাক্স যোগাযোগকারী সত্তাগুলোকে উপস্থাপন করে। কঠিন অনুভূমিক তীর চিহ্ন তাদের মধ্যে প্রবাহিত মেসেজগুলো চিত্রিত করে, যার লেবেল ‘heartbeat’। ক্লায়েন্ট থেকে সার্ভারে পরপর তিনটি হার্টবিট পাঠানো হয় ৫-সেকেন্ডের ব্যবধানে, যা সময় নির্দেশকারী ড্যাশ করা উল্লম্ব রেখার পাশে ‘5s’ লেবেল দ্বারা নির্দেশিত। সার্ভারের পাশে, প্রতিটি হার্টবিট গ্রহণ একটি সবুজ বৃত্ত এবং ‘হার্টবিট পেয়েছি। স্ট্যাটাস অনলাইন’ টেক্সট দ্বারা চিহ্নিত করা হয়। ‘x = 30s’ সময়কালের পরে, একটি ড্যাশ করা তীর চিহ্ন একটি সময় অতিবাহিত হওয়া নির্দেশ করে। এই ৩০-সেকেন্ডের উইন্ডোর মধ্যে কোনো হার্টবিট না পাওয়ার ফলে সার্ভারের পাশে একটি লাল বৃত্ত দেখা যায় যার টেক্সট ‘৩০ সেকেন্ড পর কোনো হার্টবিট নেই। স্ট্যাটাস পরিবর্তন…’, যা ক্লায়েন্টের কাছ থেকে যোগাযোগের অভাবে সার্ভারের স্ট্যাটাসের একটি পরিবর্তন নির্দেশ করে। ডায়াগ্রামটি দৃশ্যত একটি সাধারণ কিপ-অ্যালিভ মেকানিজম প্রদর্শন করে যেখানে ক্লায়েন্ট সংযোগ বজায় রাখতে পর্যায়ক্রমে সার্ভারে হার্টবিট পাঠায় এবং সার্ভার ক্লায়েন্টের অনলাইন স্ট্যাটাস নির্ধারণ করতে এই হার্টবিটগুলো পর্যবেক্ষণ করে।] চিত্র ১৮

অনলাইন স্ট্যাটাস ফ্যানআউট (Online status fanout)

ইউজার A-এর বন্ধুরা কীভাবে স্ট্যাটাস পরিবর্তন সম্পর্কে জানবে? চিত্র ১৯ ব্যাখ্যা করে এটি কীভাবে কাজ করে। প্রেজেন্স সার্ভারগুলো একটি পাবলিশ-সাবস্ক্রাইব মডেল ব্যবহার করে, যেখানে প্রতিটি বন্ধু জোড়া একটি চ্যানেল বজায় রাখে। যখন ইউজার A-এর অনলাইন স্ট্যাটাস পরিবর্তন হয়, তখন এটি তিনটি চ্যানেলে ইভেন্টটি পাবলিশ করে, চ্যানেল A-B, A-C, এবং A-D। এই তিনটি চ্যানেলে যথাক্রমে ইউজার B, C, এবং D সাবস্ক্রাইব করে। সুতরাং, বন্ধুদের জন্য অনলাইন স্ট্যাটাস আপডেট পাওয়া সহজ। ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগ রিয়েল-টাইম ওয়েবসকেটের মাধ্যমে হয়।

[চিত্র ১৯-এর বর্ণনা: ছবিটি একটি প্রেজেন্স সার্ভার সেটআপ চিত্রিত করে এমন একটি সিস্টেম আর্কিটেকচার ডায়াগ্রাম উপস্থাপন করে। একটি কেন্দ্রীয় উপাদান, ‘প্রেজেন্স সার্ভার’ লেবেলযুক্ত, একটি ড্যাশ-লাইনের বাক্স হিসাবে চিত্রিত যার ভেতরে তিনটি অনুভূমিকভাবে সাজানো উপ-উপাদান রয়েছে, প্রতিটি একটি যোগাযোগ চ্যানেল উপস্থাপন করে: ‘চ্যানেল A-B,’ ‘চ্যানেল A-C,’ এবং ‘চ্যানেল A-D’। প্রতিটি চ্যানেল দৃশ্যত তিনটি আইকন দ্বারা উপস্থাপিত যা মেইলবক্সের মতো দেখতে, যা একাধিক মেসেজ কিউ বা অনুরূপ ডেটা স্ট্রাকচার নির্দেশ করে। বাম দিক থেকে, ‘ইউজার A’ লেবেলযুক্ত একটি ডিভাইস কঠিন রেখার মাধ্যমে তিনটি চ্যানেলের প্রতিটির সাথে সংযুক্ত। ডান দিক থেকে, ‘ইউজার B,’ ‘ইউজার C,’ এবং ‘ইউজার D’ (যথাক্রমে একটি স্মার্টফোন, স্মার্টফোন এবং ল্যাপটপ) লেবেলযুক্ত ডিভাইসগুলো প্রতিটি একটি চ্যানেলের সাথে সংযুক্ত। চ্যানেলগুলোতে ব্যবহারকারীদের সংযোগ ‘subscribe’ লেবেলযুক্ত, যা একটি সাবস্ক্রিপশন-ভিত্তিক যোগাযোগ মডেল নির্দেশ করে যেখানে ব্যবহারকারীরা তথ্য পেতে নির্দিষ্ট চ্যানেলে সাবস্ক্রাইব করে। সামগ্রিক কাঠামোটি একটি পাবলিশ-সাবস্ক্রাইব সিস্টেম নির্দেশ করে যেখানে ইউজার A চ্যানেলগুলোতে তথ্য পাবলিশ করে, এবং ইউজার B, C, এবং D সেই চ্যানেলগুলো থেকে আপডেট পেতে সাবস্ক্রাইব করে।] চিত্র ১৯

উপরের ডিজাইনটি একটি ছোট ব্যবহারকারী গ্রুপের জন্য কার্যকর। উদাহরণস্বরূপ, WeChat একটি অনুরূপ পদ্ধতি ব্যবহার করে কারণ এর ব্যবহারকারী গ্রুপ ৫০০-এ সীমাবদ্ধ। বড় গ্রুপের জন্য, সমস্ত সদস্যকে অনলাইন স্ট্যাটাস সম্পর্কে জানানো ব্যয়বহুল এবং সময়সাপেক্ষ। ধরে নিন একটি গ্রুপে ১০০,০০০ সদস্য আছে। প্রতিটি স্ট্যাটাস পরিবর্তন ১০০,০০০টি ইভেন্ট তৈরি করবে। পারফরম্যান্স বটলনেক সমাধান করতে, একটি সম্ভাব্য সমাধান হলো শুধুমাত্র তখন অনলাইন স্ট্যাটাস আনা যখন একজন ব্যবহারকারী একটি গ্রুপে প্রবেশ করে বা ম্যানুয়ালি বন্ধুদের তালিকা রিফ্রেশ করে।