সোশ্যাল নেটওয়ার্ক ডিজাইন

সমস্যাটি বোঝা (Understanding the Problem)

ফেসবুকের (Facebook) মতো একটি সোশ্যাল নেটওয়ার্ক ডিজাইন করতে হবে — এমন একটি প্ল্যাটফর্ম যেখানে ব্যবহারকারীরা প্রোফাইল তৈরি করতে পারেন, বন্ধুদের সাথে যুক্ত হতে পারেন, কনটেন্ট শেয়ার করতে পারেন এবং একটি পারসোনালাইজড (personalized) নিউজ ফিড স্ক্রল করতে পারেন।

ডিজাইন করার জন্য এটি সবচেয়ে জটিল সিস্টেমগুলোর মধ্যে একটি, কারণ এটি একইসাথে গ্রাফ (graphs), রিয়েল-টাই মিলিটারি ফিড (real-time feeds), মেসেজিং (messaging), সার্চ (search) এবং বিশাল বিশাল ডেটা নিয়ে কাজ করে।

ফাংশনাল প্রয়োজনীয়তা (Functional Requirements):

• প্রোফাইল তৈরি করা (Create profile): ব্যবহারকারীরা সাইন আপ (Sign up) করতে পারবেন, প্রোফাইল পিকচার, বায়ো (bio) এবং ব্যক্তিগত তথ্য সেট করতে পারবেন।
• বন্ধু যুক্ত করা (Add friends): ফ্রেন্ড রিকোয়েস্ট পাঠানো/গ্রহণ করা, যার মাধ্যমে একটি দ্বিমুখী (bidirectional) সংযোগ তৈরি হয়।
• কনটেন্ট পোস্ট করা (Post content): টাইমলাইনে (timeline) টেক্সট, ছবি এবং ভিডিও শেয়ার করা।
• নিউজ ফিড (News feed): বন্ধু এবং ফলো (follow) করা পেজগুলোর পোস্ট নিয়ে তৈরি একটি পারসোনালাইজড বা সাজানো ফিড।
• ব্যবহারকারী খোঁজা (Search users): নাম, ইমেইল বা মিউচুয়াল (mutual) ফ্রেন্ডের মাধ্যমে মানুষ খুঁজে বের করা।

নন-ফাংশনাল প্রয়োজনীয়তা (Non-Functional Requirements):

• প্রায় ল্যাটেন্সিহীন বা লো ল্যাটেন্সি ফিড (Low latency feed): নিউজ ফিড অবশ্যই ৫০০ মিলিসেকেন্ডের মধ্যে লোড হতে হবে — কারণ ব্যবহারকারীরা ইনস্ট্যান্ট বা সাথে সাথে কনটেন্ট দেখতে প্রত্যাশা করেন।
• বিলিয়ন বিলিয়ন সম্পর্ক সামলানো (Handle billions of relationships): এখানকার সোশ্যাল গ্রাফে ২ বিলিয়ন বা ২০০ কোটিরও বেশি নোড (nodes) এবং শত শত বিলিয়ন এজ বা সংযোগ (edges) রয়েছে।
• উচ্চ প্রাপ্যতা বা অ্যাভেইলেবিলিটি (High availability): সিস্টেম ৯৯.৯৯% আপটাইমে থাকতে হবে। সোশ্যাল নেটওয়ার্কগুলো হলো সর্বদা চালু থাকা সার্ভিস।
• ইভেনচুয়ালি কনসিস্টেন্ট (Eventually consistent): একটি নতুন পোস্ট কোনো বন্ধুর ফিডে সাথে সাথেই যে দেখা যেতে হবে এমন নয় — কয়েক সেকেন্ড দেরি হলেও তা গ্রহণযোগ্য।

অ্যাস্টিমেশন (Estimation)

চলুন এই সিস্টেমের সাইজ পরিমাপ করি:

• মোট ২ বিলিয়ন ইউজার, এবং ৫০০ মিলিয়ন দৈনিক সক্রিয় ইউজার (DAU)
• গড়ে প্রতি ইউজারের ৩০০ জন বন্ধু — এর মানে ৩০০ বিলিয়ন ফ্রেন্ডশিপ এজ বা দ্বিমুখী সংযোগ
• প্রতিদিন ১০ মিলিয়ন নতুন পোস্ট — গড়ে প্রায় ১১৫ পোস্ট/সেকেন্ড, কিছু পিক আওয়ারে (Peaks) এটি ৫-১০ গুণ বেড়ে যায়
• নিউজ ফিড রিড (News feed reads): যদি প্রতিটি DAU দিনে ২০ বার তাদের ফিড চেক করে, তবে সেটি প্রতিদিন ১০ বিলিয়ন ফিড রিড (~১১৫ হাজার রিড/সেকেন্ড)
• স্টোরেজ (Storage): ইউজার প্রোফাইল একেকটি প্রায় ১ KB করে = ২ TB। মিডিয়া মেটাডেটা (media metadata) সহ পোস্টগুলো প্রায় ৫ KB করে, দিনে ১০ মিলিয়ন × ৩৬৫ × ৫ বছর ≈ ৯০ TB। ছবি বা ভিডিওর মতো মিডিয়াগুলো অবজেক্ট স্টোরেজে (object storage) থাকবে — যার আকার হবে কয়েক পেটাবাইট (petabytes)।
• গ্রাফ ডেটা স্টোরেজ (Graph storage): ৩০০ বিলিয়ন এজ × প্রতিটি ~১৬ বাইটস (দুটি ইউজার আইডি) ≈ শুধু কানেকশনের ডেটার জন্যই ৫ TB মেমোরি লাগবে

এটি একটি রিড-হেভি (read-heavy), গ্রাফ-হেভি (graph-heavy) বা প্রচুর পরিমাণে ডেটা পড়াসম্পন্ন ডেটাবেস নির্ভর সিস্টেম। বিশাল স্কেলে নিউজ ফিড এবং সোশ্যাল গ্রাফ হলো সমাধান করার মতো সবচেয়ে কঠিন দুইটি সমস্যা।

ডেটা মডেল (Data Models)

কোর বা প্রধান ডেটাগুলো এবং তাদের মধ্যকার সম্পর্কগুলো যেমন হবে:

ইউজার প্রোফাইল (User Profile): user_id, name, email, profile_pic_url, bio, created_at ইত্যাদি। একটি রিলেশনাল ডেটাবেসে (PostgreSQL) সংরক্ষিত থাকে — কারণ এটি জটিল কোয়েরিসম্পন্ন স্ট্রাকচারড (structured) ডেটা।

বন্ধুত্ব বা সোশ্যাল গ্রাফ (Friendship - Social Graph): একটি অ্যাডজাসেন্সি লিস্ট (adjacency list) রিপ্রেজেন্টেশন — যেখানে প্রতিটি ইউজারের জন্য তাদের বন্ধুদের আইডিগুলোর (ID) একটি লিস্ট স্টোর বা সেভ করা থাকে। এটিই হলো এই সিস্টেমের মূল ভিত্তি বা হার্ট।

• অপশন এ — রিলেশনাল (Relational): একটি friendships টেবিল যেখানে (user_id_1, user_id_2, status, created_at) থাকে। এটি সহজ, তবে গ্রাফ ট্রাভার্সালগুলোর বা গ্রাফগুলোতে খোঁজাখুঁজির জন্য (বন্ধুর-বন্ধু বের করার ক্ষেত্রে সেল্ফ-জয়েন বা self-joins প্রয়োজন) বেশ ব্যয়বহুল বা স্লো।
• অপশন বি — গ্রাফ ডেটাবেস (Graph Database): Neo4j অথবা TAO (যেটি ফেসবুকের গ্রাফ স্টোর) ব্যবহার করা। এটি "mutual friends" এবং "people you may know" বা যাদের আপনি চিনতে পারেন — এমন ট্রাভার্সালগুলোর জন্য সবচেয়ে অপটিমাইজড (optimized)।
• অপশন সি — কী-ভ্যালু (key-value) স্টোরে অ্যাডজাসেন্সি লিস্ট: কী (Key) = ইউজার আইডি, ভ্যালু (Value) = বন্ধুদের আইডির লিস্ট। এটি বেশ দ্রুত রিড (read) করতে পারে, কিন্তু নির্দিষ্ট সম্পর্ক বা রিলেশনশিপ খুঁজে বের করা কঠিন হয়ে যায়।

পোস্ট (Post): post_id, author_id, content, media_urls, created_at, privacy_level ইত্যাদি তথ্য। দ্রুত টাইমলাইন রিড বা পড়ার সুবিধার জন্য এটি একটি ওয়াইড-কলাম স্টোরে (wide-column store) (যেমন, Cassandra) রাখা থাকে এবং যা ইউজারের আইডির ওপর ভিত্তি করে ভাগ বা পার্টিশন (partition) করা থাকে।

কমেন্ট (Comment) এবং লাইক (Like): এগুলো পোস্টের সাথে লিংক করা থাকে। এখানে প্রচুর রাইট (write) ট্রাফিক থাকে — বিশেষ করে কোনো পোস্ট ভাইরাল হলে লাইকের সংখ্যা হঠাৎ করে বেড়ে যেতে পারে। প্রায়শই এগুলোকে আলাদা টেবিল/স্টোরে রাখা হয় যা কাউন্টার (counters) গণনার জন্য অপটিমাইজড থাকে।

ফিড জেনারেশন (Feed Generation): ফ্যান-আউট (Fan-Out) স্ট্র্যাটেজি

নিউজ ফিড হলো সিস্টেমের সবথেকে কঠিন অংশ। যখন ইউজার A (এ) একটি পোস্ট শেয়ার করেন, তখন তার ৩০০ জন বন্ধুর নিউজ ফিডে সেই পোস্টটি কীভাবে যায়?

ফ্যান-আউট অন রাইট (পুশ মডেল) (Fan-out on Write - Push Model):

• যখন কোনো ইউজার পোস্ট শেয়ার করেন, তখন সেটি সাথে সাথেই তার সব বন্ধুর আগে থেকে তৈরি করে রাখা ফিড ক্যাশে (feed cache) পুশ বা দিয়ে দেওয়া হয়।
• সুবিধা: ফিড রিডের সময় খুব দ্রুত রেজাল্ট আসে — কারণ তৈরি থাকা ক্যাশ থেকে সরাসরি ফেচ বা নেওয়া যায়। এর রিড ল্যাটেন্সি মূলত O(1)।
• অসুবিধা: সেলিব্রেটি বা প্রচুর ফলোয়ার থাকা অ্যাকাউন্টের সমস্যা। কোনো ইউজারের যদি ১০ মিলিয়ন ফলোয়ার থাকে, তবে একটি পোস্ট করলে তা ১০ মিলিয়ন বার ফিডে লেখার (cache writes) কাজ শুরু করে দেয়। এটি অত্যন্ত ধীর এবং ব্যয়বহুল একটি প্রক্রিয়া।

ফ্যান-আউট অন রিড (পুল মডেল) (Fan-out on Read - Pull Model):

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

হাইব্রিড পদ্ধতি (ফেসবুক যেভাবে কাজ করে) (Hybrid Approach):

• সাধারণ ইউজারদের জন্য (যাদের ফলোয়ার সংখ্যা ৫ হাজারের কম): ফ্যান-আউট অন রাইট (Fan-out on write) ব্যবহার করা হয়। পোস্ট করা মাত্র সেটি বন্ধুদের ফিড ক্যাশ পুশ হয়ে যায়।
• সেলিব্রিটি/পেজের জন্য (যাদের মিলিয়ন মিলিয়ন ফলোয়ার থাকে): ফ্যান-আউট অন রিড (Fan-out on read) ব্যবহার করা হয়। সেলিব্রিটিদের পোস্টগুলো রিয়েল-টাইমে রিড করার সময় এনে সাধারণ ফিড পোস্টের সাথে মার্জ করা হয়।
• এই মডেলটি দুটি পদ্ধতির সেরা অংশগুলো আমাদের দেয় — বেশিরভাগ সাধারণ ইউজারের দ্রুত ফিড রিডের সুবিধা দেয় এবং সেলিব্রিটিদের জন্য একসঙ্গে মিলিয়ন রাইট অপারেশনের সমস্যা থেকে রক্ষা করে।

গ্রাফ ট্রাভার্সাল এবং ফ্রেন্ড সাজেশন (Graph Traversal & Friend Suggestions)

সোশ্যাল গ্রাফ শুধু বন্ধুদের তালিকা দেখার চেয়েও আরও শক্তিশালী কিছু ফিচার বা বৈশিষ্ট্য তৈরি করতে সহায়তা করে:

বন্ধুর বন্ধু বা ফ্রেন্ড-অফ-ফ্রেন্ড সাজেশন (Friend-of-Friend Suggestions - "People You May Know"):

• এটি এমন ইউজারদের খুঁজে বের করে যারা ২ হপ (hop) দূরে আছেন: অর্থাৎ, আপনার বন্ধুদের বন্ধু, যারা এখনও আপনার বন্ধু নন।
• এরপর এগুলোকে মিউচুয়াল কানেকশনের (mutual connections) সংখ্যার ভিত্তিতে র‍্যাঙ্ক করা হয় — মিউচুয়াল বন্ধুর সংখ্যা যত বেশি, সাজেশনটি তত জোরালো।
• এটি গ্রাফে BFS/2-hop ট্রাভার্সালের মাধ্যমে করা হয়। বড় স্কেল বা বিশাল গ্রাফের ক্ষেত্রে (যেমন, গড়ে ৩০০ বন্ধু × ৩০০ = ৯০ হাজার ক্যান্ডিডেট), এটি আগে থেকেই ক্যালকুলেট বা প্রি-কম্পিউট (pre-computed) করে ক্যাশ করে রাখতে হয়।

মিউচুয়াল ফ্রেন্ড (Mutual Friends):

• এটি মূলত ২ জন ইউজারের ফ্রেন্ড লিস্টের ইন্টারসেকশন (Intersection) বা উভয়ের চেনা বন্ধুদের তালিকা দেখার কাজটি করে। সর্টেড (sorted) অ্যাডজাসেন্সি লিস্ট দিয়ে এটি O(n) মার্জ অপারেশন সম্পন্ন করে।
• এটি সাধারণত প্রোফাইলে দেখানো হয় এবং ট্রাস্ট সিগন্যাল (trust signals) হিসেবে ব্যবহৃত হয়।

প্রাইভেসি এবং অ্যাক্সেস কন্ট্রোল (Privacy & Access Control):

• প্রতিটি পোস্টের নির্দিষ্ট প্রাইভেসি লেভেল বা গোপনীয়তার ধরন থাকে: যেমন পাবলিক, ফ্রেন্ডস-ওনলি (শুধু বন্ধুদের জন্য), ফ্রেন্ডস-অফ-ফ্রেন্ডস (বন্ধুদের বন্ধুদের জন্য) অথবা কাস্টম লিস্ট।
• ফিড জেনারেশনের সময় অবশ্যই প্রাইভেসি চেক করতে হয় — যেমন ভিউয়ার এই পোস্টটি দেখার অনুমতি রাখেন কিনা?
• গ্রাফ কোয়েরিগুলো এই কাজটির জন্যই প্রয়োজনীয়: "ভিউয়ার কি পোস্টদাতার বন্ধু?" — এটি যাচাই করার কাজটি O(1) সময় নিতে হয়। এই কারণে প্রত্যেক ইউজারের ফ্রেন্ড লিস্ট একটি হ্যাশ সেট (hash set) হিসেবে রাখা উচিত।