System Design Core Concepts: Theory & Q&A
সিস্টেম ডিজাইন ইন্টারভিউতে সবচেয়ে বেশি জিজ্ঞাসিত কোর কনসেপ্টগুলোর বিস্তারিত থিওরি এবং প্রশ্নোত্তর নিচে দেওয়া হলো।
১. স্কেলেবিলিটি, এভেইল্যাবিলিটি এবং রিলায়েবিলিটি
ক. স্কেলেবিলিটি (Scalability)
থিওরি: স্কেলেবিলিটি হলো কোনো সিস্টেমের বাড়তি লোড বা ট্রাফিক হ্যান্ডেল করার ক্ষমতা। এটি প্রধানত দুই প্রকার:
- Vertical Scaling: একটি পিসির রিসোর্স (CPU, RAM) বাড়ানো।
- Horizontal Scaling: সিস্টেমে আরও বেশি পিসি/সার্ভার যুক্ত করা।
প্রশ্ন: কখন আপনি Horizontal স্কেলিং পছন্দ করবেন? উত্তর: যখন সিস্টেমের গ্রোথ অনেক বেশি এবং একটি সিঙ্গেল সার্ভারের পাওয়ার বাড়ানো আর সম্ভব না (Limit reached), তখন Horizontal স্কেলিং সবচেয়ে ভালো সমাধান। এটি Redundancy নিশ্চিত করে এবং সিঙ্গেল পয়েন্ট অফ ফেইলিওর কমায়।
খ. এভেইল্যাবিলিটি (Availability)
থিওরি: সিস্টেমটি সব সময় ইউজারদের জন্য সচল থাকার ক্ষমতা। এটি সাধারণত 'nines' দিয়ে প্রকাশ করা হয় (উদা: 99.99% availability)।
গ. রিলায়েবিলিটি (Reliability)
থিওরি: সিস্টেমটি ভুল ছাড়াই নির্দিষ্ট সময়ে সঠিকভাবে কাজ করার ক্ষমতা। একটি রিলায়েবল সিস্টেম মানে হলো এটি ফেইল করবে না।
২. কনসিস্টেন্সি মডেল এবং CAP Theorem
ক. কনসিস্টেন্সি মডেল (Consistency Models)
- Strong Consistency: ডেটা লেখার সাথে সাথেই সব রিড রিকোয়েস্টে আপডেট ভ্যালু পাওয়া যাবে। (উদা: ব্যাংকিং ট্রানজেকশন)।
- Eventual Consistency: ডেটা লেখার পর কিছু সময় লাগতে পারে সব জায়গায় আপডেট হতে, কিন্তু এক সময় সবাই আপডেট ভ্যালু পাবে। (উদা: ফেসবুক লাইক বা টুইট)।
খ. CAP Theorem
থিওরি: ডিস্ট্রিবিউটেড সিস্টেমে Consistency (C), Availability (A), এবং Partition Tolerance (P) - এই তিনটির মধ্যে একসাথে সর্বোচ্চ দুইটি নিশ্চিত করা সম্ভব।
প্রশ্ন: CAP থিউরেমে কেন Partition Tolerance (P) সবসময় বাধ্যতামূলক? উত্তর: একটি নেটওয়ার্ক সিস্টেমে যেকোনো সময় কানেকশন ব্রেক (Network Partition) হতে পারে। তাই ডিস্ট্রিবিউটেড সিস্টেমে আমাদের হয় CP (Consistency) বেছে নিতে হবে অথবা AP (Availability)।
৩. কনসিস্টেন্ট হ্যাশিং (Consistent Hashing)
থিওরি: যখন একাধিক সার্ভারে ডেটা ডিস্ট্রিবিউট করা হয় এবং হঠাৎ কোনো সার্ভার যুক্ত বা রিমুভ হয়, তখন রি-হ্যাশিংয়ের পরিমাণ কমানোর পদ্ধতিই হলো কনসিস্টেন্ট হ্যাশিং।
প্রশ্ন: কেন সাধারণ হ্যাশিংয়ের পরিবর্তে কনসিস্টেন্ট হ্যাশিং ব্যবহার করা হয়? উত্তর: সাধারণ হ্যাশিংয়ে (key % n) যদি সার্ভার সংখ্যা (n) পরিবর্তন হয়, তবে প্রায় সব ডেটা মুভ করতে হয়। কিন্তু কনসিস্টেন্ট হ্যাশিংয়ে গড়ে মাত্র k/n সংখ্যক ডেটা মুভ করতে হয়, যা ক্যাশ এবং ডাটাবেস স্কেলিংয়ের জন্য অত্যন্ত কার্যকর।
৪. ল্যাটেন্সি বনাম থ্রুপুট (Latency vs Throughput)
- Latency: একটি রিকোয়েস্ট শুরু থেকে শেষ হতে মোট কত সময় লাগে (Time)। উদা: ১০০ মিলিসেকেন্ড।
- Throughput: একটি নির্দিষ্ট সময়ে সিস্টেম কতগুলো রিকোয়েস্ট প্রসেস করতে পারে (Volume)। উদা: ৫০০ রিকোয়েস্ট প্রতি সেকেন্ড।
টিপ: সবসময় চেষ্টা করা হয় ল্যাটেন্সি কমাতে এবং থ্রুপুট বাড়াতে।
৫. সিঙ্গেল পয়েন্ট অফ ফেইলিওর (SPOF)
থিওরি: সিস্টেমের এমন একটি কম্পোনেন্ট যা ফেইল করলে পুরো সিস্টেম বন্ধ হয়ে যায়।
প্রশ্ন: কীভাবে আপনি SPOF দূর করবেন? উত্তর: Redundancy ব্যবহারের মাধ্যমে। প্রতিটি কম্পোনেন্টের (Load balancer, Database, Server) অন্তত একটি ব্যাকআপ বা ডুপ্লিকেট রাখতে হবে যাতে একটি ফেইল করলেও অন্যটি কাজ চালিয়ে নিতে পারে।
৬. সিনারিও ভিত্তিক প্রশ্ন (Scenario-based Questions)
ইন্টারভিউতে আপনাকে কিছু বাস্তব পরিস্থিতি দেওয়া হতে পারে। নিচে এমন কিছু কমন সিনারিও দেওয়া হলো:
সিনারিও ১: "আপনার সিস্টেমে হঠাৎ ট্রাফিক ১০ গুণ বেড়ে গেছে, কিন্তু আপনার ডাটাবেস স্লো হয়ে গেছে। আপনি কী করবেন?"
সমাধান: ১. Caching: প্রথমে চেক করব পপুলার কুয়েরিগুলো Redis বা Memcached দিয়ে ক্যাশ করা যায় কি না। ২. Read Replicas: ডাটাবেসে অনেক বেশি রিড রিকোয়েস্ট থাকলে Read Replicas তৈরি করব। ৩. Database Sharding: যদি একটি ডাটাবেস আর লোড নিতে না পারে, তবে ডেটা ভিন্ন ভিন্ন সার্ভারে ভাগ (Shard) করে দেব। ৪. Indexing: ডাটাবেস কুয়েরিগুলো অপ্টিমাইজড কি না এবং ইনডেক্সিং ঠিক আছে কি না তা চেক করব।
সিনারিও ২: "ফেসবুকের মতো একটি নিউজফিড সিস্টেমে আপনি কনসিস্টেন্সি নাকি এভেইল্যাবিলিটি বেছে নেবেন?"
সমাধান: নিউজফিডের ক্ষেত্রে Availability (AP) বেশি গুরুত্বপূর্ণ। যদি এক বন্ধুর পোস্ট অন্য বন্ধু ২-৩ সেকেন্ড পরে দেখে, তাতে খুব বড় সমস্যা হবে না (Eventual Consistency)। কিন্তু ইউজার যদি নিউজফিড রিফ্রেশ করে এরর কার্ড দেখে, তবে ইউজার এক্সপেরিয়েন্স খারাপ হবে। তাই এখানে Eventual Consistency বেছে নেওয়া সঠিক সিদ্ধান্ত।
সিনারিও ৩: "একটি ই-কমার্স ফ্ল্যাশ সেলের সময় কীভাবে ইনভেন্টরি ওভার-সেলিং (Over-selling) ঠেকাবেন?"
সমাধান: ১. Distributed Locking: Redis বা অন্য কোনো পদ্ধতিতে ইনভেন্টরি স্টকের ওপর লক ব্যবহার করব যাতে দুইজন ইউজার একই সাথে শেষ আইটেমটি কিনতে না পারে। ২. Optimistic Locking: ডাটাবেস লেভেলে ভার্সন চেক করে আপডেট করব। ৩. Queueing: অতিরিক্ত রিকোয়েস্টগুলো মেসেজ কিউতে রেখে প্রসেস করব যাতে মেইন ডাটাবেসে রিকোয়েস্ট লিমিটেড থাকে।
IMPORTANT
ইন্টারভিউয়ার আপনার কাছ থেকে শুধু পড়াশোনা করা উত্তর চান না, তিনি দেখতে চান আপনি বাস্তব জীবনে কীভাবে ডিজাইন ডিসিশন নেন। তাই প্রতিটি কনসেপ্টের ট্রেড-অফগুলো মাথায় রাখুন।