Fundamentalsপড়তে ১০ মিনিট লাগবে

স্কেলেবিলিটি (Scalability)

এক ইউজার থেকে এক বিলিয়ন — সিস্টেম কীভাবে বড় হয়

scope:ফাউন্ডেশনাল (Foundational)difficulty:বিগিনার (Beginner)

স্কেলেবিলিটি কী? (What is Scalability?)

কল্পনা করুন আপনি একটি চায়ের দোকান চালান। সোমবারে ৫ জন কাস্টমার আসলো — আপনি সহজেই সামলে নিলেন। শুক্রবারে একটা বড় টুর্নামেন্টের সব দর্শক চলে আসলো — ৫০০ জন। আপনার দোকান কি সেটা সামলাতে পারবে?

স্কেলেবিলিটি হলো আপনার সিস্টেমের বড় হওয়ার ক্ষমতা — আরও ইউজার, আরও ডাটা, আরও রিকোয়েস্ট — কোনো কিছু ক্র্যাশ না করেই সামলে নেওয়া। একটা স্কেলেবল সিস্টেম ১০ জন ইউজারের জন্য যেমন কাজ করবে, ১ কোটি ইউজারের জন্যও ঠিক তেমনই কাজ করবে।

স্কেল করার মূলত দুটি উপায় আছে, এবং সেগুলো আপনার চায়ের কেটলি আপগ্রেড করা আর আরও অনেক কেটলি কেনার মতোই আলাদা।

▸ একটি ছোট সার্ভার — যেখান থেকে প্রতিটি অ্যাপ শুরু হয়

ভার্টিকাল স্কেলিং (Vertical Scaling - Scale Up)

ভার্টিকাল স্কেলিং মানে আপনার বর্তমান মেশিনকে আকারে বড় এবং শক্তিশালী (Bigger and stronger) করা। আরও CPU, আরও RAM, আরও ফাস্ট ডিস্ক লাগানো। এটা অনেকটা আপনার সাইকেল বদলিয়ে একটা মোটরসাইকেল কেনার মতো ব্যাপার।

সুবিধা (Pros):

সহজ — কোনো কোড পরিবর্তনের দরকার নেই। জাস্ট হার্ডওয়্যার আপগ্রেড করুন।
ডিস্ট্রিবিউটেড সিস্টেমের মাথা ব্যথা নেই (সার্ভারগুলোর মধ্যে কোনো নেটওয়ার্ক ইস্যু নেই)।
সবকিছু এক মেশিনে থাকায় ডাটা কনসিস্টেন্সি রক্ষা করা সহজ।

অসুবিধা (Cons):

এর একটা সীমা আছে (Ceiling)। পৃথিবীর সবচেয়ে বড় সার্ভারেরও লিমিট আছে।
খুবই ব্যয়বহুল। এন্টারপ্রাইজ-গ্রেড হার্ডওয়্যারের অনেক দাম।
সিঙ্গেল পয়েন্ট অফ ফেইলিউর (Single point of failure)। যদি সেই একটিমাত্র শক্তিশালী সার্ভার নষ্ট হয়ে যায়, তাহলে পুরো সিস্টেম ডাউন।

এটাকে একটা হোটেলের বড় চুলার মতো ভাবতে পারেন। আপনি আরও বড়, আরও গরম চুলা তৈরি করতে পারেন — কিন্তু শেষমেশ এর চেয়ে বড় চুলা আর বানানো সম্ভব হবে না। আর সেটা নষ্ট হলে, কেউই আর খাবার পাবে না!

▸ ভার্টিকাল স্কেলিং — সার্ভারকে আরও শক্তি দিন

▸ সীমা (The ceiling) — আপনি সারা জীবন ধরে শুধু আপগ্রেড করতে পারবেন না

হরাইজন্টাল স্কেলিং (Horizontal Scaling - Scale Out)

হরাইজন্টাল স্কেলিং মানে একটি মেশিন আপগ্রেড করার বদলে আরও মেশিন যোগ করা। একটা বিশালাকার পিৎজা ওভেন কেনার বদলে, শহরের এমাথা থেকে ওমাথা পর্যন্ত ১০টা পিৎজা শপ খোলা।

সুবিধা (Pros):

প্রায় অসীম গ্রোথ। আরও ক্যাপাসিটি দরকার? শুধু আরও সার্ভার যোগ করুন।
বেটার ফল্ট টলারেন্স (Fault tolerance)। একটা সার্ভার নষ্ট হলে, অন্যগুলো কাজ চালিয়ে নিতে পারে।
দামি সুপার-কম্পিউটারের বদলে সস্তা, সাধারণ (Commodity) হার্ডওয়্যার ব্যবহার করা যায়।

অসুবিধা (Cons):

জটিলতা (Complexity)! আপনার কোড এখন অনেকগুলো মেশিনে চলে। তারা কীভাবে ডাটা শেয়ার করবে? তারা কীভাবে সিঙ্ক রাখবে?
মেশিনগুলোর মধ্যে নেটওয়ার্ক ল্যাটেন্সি যোগ হয়।
আপনার লোড ব্যাল্যান্সার, ডিস্ট্রিবিউটেড ডাটাবেস এবং এরকম আরও অনেক মজার জিনিস লাগবে।

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

▸ হরাইজন্টাল স্কেলিং — আরও মেশিন যোগ করুন

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

স্টেটফুল বনাম স্টেটলেস সার্ভিস (Stateless vs Stateful Services)

হরাইজন্টাল স্কেলিংয়ের জন্য এটি সবচেয়ে গুরুত্বপূর্ণ কনসেপ্টগুলোর একটি। চলুন বিস্তারিত দেখা যাক।

একটি স্টেটফুল (Stateful) সার্ভার প্রতিটি ইউজার সম্পর্কে তথ্য মনে রাখে। "ওহ আচ্ছা, আপনি ইউজার #৪২, এবং আপনার কার্টে ৩টি আইটেম আছে।" সমস্যা কোথায়? যদি আপনি ইউজার #৪২ কে অন্য সার্ভারে পাঠান, ঐ সার্ভারের তার সম্পর্কে কোনো ধরণাই থাকবে না। এটি অনেকটা আপনার ব্যাংকের অন্য ব্র্যাঞ্চে কল করার মতো, যেখানে আপনার অ্যাকাউন্ট সম্পর্কে তাদের কোনো রেকর্ডই নেই।

একটি স্টেটলেস (Stateless) সার্ভার প্রতিটি রিকোয়েস্টকে একেবারে নতুন হিসেবে বিবেচনা করে। তার যে তথ্যগুলো দরকার তা রিকোয়েস্টের সাথেই আসে (অথবা বাইরের কোনো স্টোর যেমন ডাটাবেস বা ক্যাশ থেকে আসে)। যেকোনো সার্ভার যেকোনো রিকোয়েস্ট হ্যান্ডেল করতে পারে।

এটা কেন গুরুত্বপূর্ণ? হরাইজন্টাল স্কেলিংয়ের ক্ষেত্রে স্টেটলেস সার্ভিস ম্যাজিকের মতো কাজ করে। আরও ক্যাপাসিটি দরকার? একটা লোড ব্যাল্যান্সারের পেছনে আরও ৫০টি সার্ভার বসিয়ে দিন। প্রতিটি সার্ভার হুবহু একই এবং ইন্টারচেঞ্জেবল — অনেকটা এটিএম (ATM) মেশিনের মতো।

স্টেটফুল সার্ভিস নিয়ে কাজ করা একটু ঝামেলার। আপনাকে হয় স্টিকি সেশন (Sticky sessions) ব্যবহার করতে হবে (একই ইউজারকে সবসময় একই সার্ভারে পাঠানো) অথবা স্টেটটিকে বাইরে রাখতে হবে (যেমন Redis বা অন্য কোনো ডাটাবেসে)।

▸ স্টেটলেস হওয়াই মূল চাবিকাঠি — সেশন স্টেটকে বাইরে রাখুন

স্টেটফুল বনাম স্টেটলেস সার্ভারের উদাহরণ

# BAD: Stateful server — stores cart in memory
class StatefulServer:
    def __init__(self):
        self.carts = {}  # user_id -> items (lives in this server's RAM)

    def add_to_cart(self, user_id, item):
        if user_id not in self.carts:
            self.carts[user_id] = []
        self.carts[user_id].append(item)
        # Problem: if the user's next request goes to another server,
        # all their cart items will be gone!

# GOOD: Stateless server — stores cart in external Redis
import redis

class StatelessServer:
    def __init__(self):
        self.cache = redis.Redis(host='redis-cluster', port=6379)

    def add_to_cart(self, user_id, item):
        cart_key = f"cart:{user_id}"
        self.cache.rpush(cart_key, item)
        # Any server can handle this user's next request!
        # The cart lives in Redis, not in this server's memory.

# Scaling with stateless servers is straightforward:
# Load Balancer -> [Server 1, Server 2, Server 3, ... Server N]
# All servers are identical and interchangeable.

Output

# Stateless servers can scale horizontally without session issues

সিঙ্গেল পয়েন্ট অফ ফেইলিউর (Single Points of Failure - SPOF)

একটি সিঙ্গেল পয়েন্ট অফ ফেইলিউর হলো সিস্টেমের এমন কোনো অংশ যা ফেল করলে পুরো সিস্টেম ডাউন হয়ে যায়। এটি হলো একটা চেইনের সবচেয়ে দুর্বল লিংক।

উদাহরণস্বরূপ:

কোনো রেপ্লিকা ছাড়া একটিমাত্র ডাটাবেস সার্ভার — এটি ক্র্যাশ করলে সব ডাটা ধরাছোঁয়ার বাইরে চলে যাবে।
একটিমাত্র লোড ব্যাল্যান্সার — এটি নষ্ট হয়ে গেলে সার্ভারে কোনো ট্রাফিক পৌঁছাবে না।
একটিমাত্র DNS প্রোভাইডার — এটি ডাউন হলে কেউই আপনার ওয়েবসাইট খুঁজে পাবে না।

এর সমাধান কী? রিডান্ডেন্সি (Redundancy)। প্রতিটি গুরুত্বপূর্ণ উপাদানের কমপক্ষে দুটির ব্যাকআপ রাখুন। দুটি লোড ব্যাল্যান্সার (অ্যাক্টিভ-প্যাসিভ বা অ্যাক্টিভ-অ্যাক্টিভ ব্যবস্থা)। একাধিক ডাটাবেস রেপ্লিকা। ক্লাউডে একাধিক অ্যাভেইলেবিলিটি জোন।

এটাকে একটা বনাম চারটি খুঁটির ব্রিজের মতো ভাবতে পারেন। চার খুঁটির ব্রিজে একটা খুঁটিতে ফাটল ধরলেও ব্রিজ দাঁড়িয়ে থাকে।

স্কেলিংয়ের বাস্তব গল্প (Real Scaling Stories)

চলুন দেখি বাস্তব দুনিয়ার বড় কোম্পানিগুলো কীভাবে স্কেল করে:

নেটফ্লিক্স (Netflix): তারা ২০ কোটির বেশি সাবস্ক্রাইবার সামলায়। তারা AWS-এ চলা হাজার হাজার মাইক্রোসার্ভিস ব্যবহার করে। প্রতিটি সার্ভিস আলাদাভাবে স্কেল করতে পারে — নতুন রিলিজের সময় শুধু ভিডিও এনকোডিং সার্ভিস স্কেল আপ হতে পারে, যার ফলে রেকমেন্ডেশন ইঞ্জিনে কোনো প্রভাব পড়ে না।

ইনস্টাগ্রাম (Instagram): লঞ্চ করার সময় তাদের মাত্র ২টি সার্ভার ছিল। ভাইরাল হওয়ার কয়েক ঘণ্টার মধ্যেই তারা বাধ্য হয়ে আরও সার্ভার যোগ করতে শুরু করে। এরপর তারা লোড ব্যাল্যান্সার, শার্ডেড ডাটাবেস এবং Redis ক্যাশিং-সহ হরিজন্টালি স্কেলড আর্কিটেকচারে চলে যায়। আজ তারা প্রতি মাসে ২০০ কোটির বেশি একটিভ ইউজার সামলায়।

টুইটার (Twitter): শুরুর দিকে হাই ট্রাফিকের সময় টুইটার প্রায়ই তাদের বিখ্যাত "ফেইল হোয়েল" (Fail Whale) এরর পেজ দেখাতো। ট্রাফিক সামলানোর জন্য তাদের পুরো আর্কিটেকচার নতুন করে ঢেলে সাজাতে হয়েছিল — তারা একটি মোনোলিথিক রুবি (Ruby) অ্যাপ থেকে ডিস্ট্রিবিউটেড জাভা সার্ভিসে চলে গিয়েছিল।

এখান থেকে কী শিখলেন? শুরু থেকেই স্কেলের কথা মাথায় রেখে ডিজাইন করুন। পরে এসে স্কেলেবিলিটি যোগ করার চেয়ে আগে থেকেই ব্যবস্থা করে রাখা অনেক বেশি সহজ।

Note: ইন্টারভিউ টিপস: যখন আপনাকে জিজ্ঞেস করা হবে "আপনি কীভাবে এটিকে স্কেল করবেন?", তখন শুধু "আরও সার্ভার যোগ করবো" বলে থেমে যাবেন না। পুরো ছবিটি তুলে ধরুন: সার্ভিসগুলোকে স্টেটলেস করুন, একটি লোড ব্যাল্যান্সার যোগ করুন, ডাটাবেস শার্ড (Shard) করুন, একটি ক্যাশ লেয়ার যোগ করুন, স্ট্যাটিক কন্টেন্টের জন্য CDN ব্যবহার করুন। প্রমাণ করুন যে স্কেলিংয়ের পুরো টুলকিট সম্পর্কে আপনার ভালো ধারণা আছে।