Scalability: vertical বনাম horizontal scaling

Scalability মানে নকশা না বদলে বেশি লোড সামলানোর ক্ষমতা। Scale up আর scale out-এর পার্থক্য এবং সিস্টেম সাধারণত কোথায় আগে ভাঙে, জেনে নিন।

ক্রমে বড় হতে থাকা কয়েকটি ব্লক

একটি সিস্টেম scalable তখনই, যখন নতুন করে না লিখেও resource যোগ করে বেশি user, data বা request সামলানো যায়। Scalability মানে "দ্রুত" নয়। একজন user-এর জন্য পেজ দ্রুত হতে পারে, কিন্তু দশ হাজার জনের চাপে বসে যেতে পারে।

Vertical scaling (scale up)

একটি মেশিনেই বেশি CPU, RAM বা disk দেওয়া।

  • সুবিধা: সহজ, কোড বদলাতে হয় না, distributed system-এর ঝামেলা নেই।
  • অসুবিধা: একটা সীমা আছে, বড় মেশিন খুব দামি, আর একটি মেশিন মানে একটিই single point of failure।

Horizontal scaling (scale out)

অনেকগুলো সাধারণ মেশিন load balancer-এর পেছনে চালানো।

  • সুবিধা: সীমা প্রায় নেই, একটি মেশিন নষ্ট হলেও সার্ভিস চলে।
  • অসুবিধা: জটিলতা বাড়ে। নেটওয়ার্ক failure, data consistency আর অনেক node-এ deploy সামলাতে হয়।

Server-কে stateless রাখুন

যেকোনো server যেকোনো request সামলাতে পারলে তবেই scale out মসৃণ হয়। তাই user session কোনো একটি server-এর memory-তে রাখবেন না। State রাখুন shared store-এ (database, Redis) অথবা signed token-এ।

সবার আগে কোথায় ভাঙে

Application server সহজে বাড়ানো যায়। Database সহজে যায় না। Read কমাতে cache আর replica আছে (পরের পর্বগুলোতে), আর write-এর জন্য শেষে sharding লাগে। মেশিন বাড়ানোর আগে মেপে দেখুন আসল bottleneck কোথায়।

যুক্তিসঙ্গত ক্রম

  1. আগে মাপুন, সবচেয়ে ধীর অংশ খুঁজুন।
  2. Query ঠিক করুন, index দিন।
  3. সস্তা হলে scale up করুন।
  4. Cache যোগ করুন, তারপর app server বাড়ান।
  5. Read replica দিন, আর অনেক পরে sharding।

মূল কথা: সহজ থেকে শুরু করুন, আগে scale up, stateless design রাখুন যাতে পরে scale out করা যায়, আর ধরে নিন কঠিন অংশটা database।


System Design সিরিজের 1 নম্বর পর্ব (মোট ১৫)।

আরও পড়ুন

Recursion ও backtracking সহজ উদাহরণে

Recursion সমস্যার ছোট কপি সমাধান করে সমাধান করে। অনেক interview সমস্যায় ব্যবহৃত চিন্তার ধাপ ও backtracking টেমপ্লেট শিখুন।

Interview ও DSA•৩ মিনিটে পড়া