System design কী — একটি অ্যাপ থেকে কোটি ব্যবহারকারীর সিস্টেম

১ · System design কী — পুরো সেবার নকশা

ফোনে mobile banking, ride-sharing, খাবার অর্ডার বা ভিডিওর অ্যাপ খুলে কখনো ভেবেছেন — একই মুহূর্তে লাখো মানুষ বোতাম চাপছেন, তবু প্রত্যেকে এক সেকেন্ডের কম সময়ে উত্তর পাচ্ছেন কীভাবে? কোনো একটি সার্ভার নষ্ট হলেও অ্যাপ চলছে কীভাবে? এর উত্তর কোনো একটি চতুর প্রোগ্রামে নেই। উত্তর আছে পুরো ব্যবস্থার নকশায় — কয়টি সার্ভার, ডেটা কোথায়, কোন অনুরোধ কোন পথে যায়, আর কোনো অংশ বিকল হলে কে দায়িত্ব নেয়। এই নকশার নামই system design.

এই কোর্স মূলত HLD নিয়ে। তবে সীমারেখা পুরো স্পষ্ট নয়: API-র রূপ (পর্ব ৮) বা টেবিল আর index-এর নকশা (পর্ব ২১) দুই জগতেরই অংশ, আর আমরা এগুলোও দেখব। নামও জায়গাভেদে আলাদা — কোথাও “architecture”, কোথাও “system design”; ইন্টারভিউতে LLD-কে কখনো “object-oriented design” বলা হয়।

২ · কেন দরকার — পাঁচটি চাপ

একটি সার্ভারে চলা ছোট অ্যাপ আর কোটি মানুষের অ্যাপের মূল কোড হয়তো প্রায় একই; পার্থক্য পরিবেশে। ব্যবহারকারী বাড়লে পাঁচটি চাপ একসাথে আসে, আর system design এই পাঁচটির মধ্যে ভারসাম্য খোঁজে:

একটি বাস্তবধর্মী দৃশ্য — পরীক্ষার ফল প্রকাশের দিন। ধরা যাক একটি ফলের সাইটে সাধারণ দিনে সারা দিনে ৫০ হাজার অনুরোধ আসে, গড়ে সেকেন্ডে একটিরও কম (প্রায় ০.৬)। ফল প্রকাশের প্রথম ১০ মিনিটে ১০ লাখ মানুষ গড়ে ৫টি করে অনুরোধ পাঠালে আসে সেকেন্ডে প্রায় ৮,৩৩৩টি — সাধারণ গড়ের ১৪,৪০০ গুণ! এমন দিনে সাইট খুলতে না চাওয়ার কারণ প্রায়ই প্রোগ্রামের ভুল নয়; নকশাটি গড়ের জন্য করা, সবচেয়ে ব্যস্ত মুহূর্তের জন্য নয়। ঈদের আগে বাসের অনলাইন টিকিটেও একই গল্প।

৩ · মহল্লার দোকান থেকে দেশজোড়া চেইন — একটি অ্যাপের বেড়ে ওঠা

এবার পুরো কোর্সের মানচিত্রটি একটি গল্পে দেখা যাক। একটি কাল্পনিক অনলাইন বাজারের অ্যাপ — চাল, ডাল, তেল অর্ডার করা যায় — শুরু করলেন দুই বন্ধু। পাশাপাশি চলবে আরেকটি গল্প: রহিম সাহেবের মহল্লার মুদি দোকান, যা ধীরে ধীরে গুদাম আর ডিপোসহ দেশজোড়া চেইন হয়ে উঠল। প্রতিটি ধাপে দুটি প্রশ্ন খেয়াল করুন: কোন সমস্যা এই বদল বাধ্য করল? আর বদলের দাম কী?

নিচের ছবিতে প্রতিটি ধাপের architecture; লাল ড্যাশ দাগে ঘেরা অংশটি সেই ধাপে নতুন। “পরে” চাপুন, অথবা “চালান” চাপলে নিজে থেকেই এগোবে।

এক নজরে — কোন চাপে কোন ধাপ

৪ · কত ব্যবহারকারীতে কোন ধাপ — DAU থেকে QPS

“কত ব্যবহারকারী” প্রশ্নটিকে সার্ভারের ভাষায় বদলাতে হয়: প্রতি সেকেন্ডে কতগুলো অনুরোধ, অর্থাৎ QPS (queries per second; ওয়েবে একে requests per second-ও বলা হয়)। হিসাব শুরু হয় DAU (daily active users — দিনে অন্তত একবার আসা ব্যবহারকারী) থেকে:

৮৬,৪০০ হলো এক দিনের সেকেন্ড (২৪ × ৬০ × ৬০)। কিন্তু মানুষ সারা দিন সমানভাবে আসেন না — সন্ধ্যায় ভিড়, রাত তিনটায় ফাঁকা। তাই সবচেয়ে ব্যস্ত সময়ের ভার গড়ের কয়েক গুণ ধরা হয়; এই গুণককে আমরা বলব peak factor. এ ধরনের মোটা দাগের দ্রুত হিসাবকে বলে back-of-the-envelope হিসাব — খামের পেছনেই কষে ফেলা যায় এমন অঙ্ক। পুরো কৌশল পর্ব ০৩-এ।

নিচের ক্যালকুলেটর DAU ১ হাজার থেকে ১০ কোটি পর্যন্ত, প্রতি ধাপে ১০ গুণ করে, হিসাব করে কোন architecture ধাপ লাগতে পারে। সব ক্ষমতা ধরে নেওয়া গোল সংখ্যা — যেমন প্রতি জন দিনে ৪০টি অনুরোধ, peak factor ৩, একটি app সার্ভার সেকেন্ডে ~৫০০ অনুরোধ, একটি database ~৫,০০০ query; বাকিগুলো কোডের মন্তব্যে। বাস্তবে কাজের ধরন অনুযায়ী এগুলো দশ গুণ এদিক-ওদিক হতে পারে।

// Growth-stage calculator. Every capacity below is an ASSUMPTION (a round
// number for teaching), not a measurement. Measure yours with a load test.
const REQ_PER_USER = 40;  // requests per daily active user per day
const PEAK = 3;           // busiest hour = 3 x the daily average
const ONE_BOX = 100;      // app + DB together on ONE machine: ~100 req/s
const APP_CAP = 500;      // one stateless app server: ~500 req/s
const DB_CAP = 5000;      // one database server: ~5,000 queries/s
const Q_PER_REQ = 2;      // database queries per request
const WRITES = 0.05;      // 5% of the queries are writes
const HIT = 0.9;          // cache hit ratio for reads, once a cache exists

function stage(peak) {
  const q = peak * Q_PER_REQ, w = q * WRITES, r = q - w;
  const afterCache = r * (1 - HIT) + w;          // DB load with a cache
  if (peak <= ONE_BOX) return "1 one server (app + DB)";
  if (peak <= APP_CAP) return "2 app server + separate DB";
  if (q <= DB_CAP) return "3 LB + stateless app servers";
  if (afterCache <= DB_CAP) return `4 + cache (DB load ${afterCache.toFixed(0)}/s)`;
  if (w <= DB_CAP) return `5 + read replicas (${Math.ceil(r * (1 - HIT) / DB_CAP)})`;
  return `8 + sharding (writes ${w.toFixed(0)}/s)`;
}

console.log("DAU          avg/s   peak/s  apps  likely stage");
for (const dau of [1e3, 1e4, 1e5, 1e6, 1e7, 1e8]) {
  const avg = dau * REQ_PER_USER / 86400, peak = avg * PEAK;
  const apps = Math.ceil(peak / APP_CAP);
  console.log(dau.toLocaleString("en-US").padEnd(12) + avg.toFixed(1).padStart(8) +
    peak.toFixed(1).padStart(9) + String(apps).padStart(6) + "  " + stage(peak));
}

DAU          avg/s   peak/s  apps  likely stage
1,000            0.5      1.4     1  1 one server (app + DB)
10,000           4.6     13.9     1  1 one server (app + DB)
100,000         46.3    138.9     1  2 app server + separate DB
1,000,000      463.0   1388.9     3  3 LB + stateless app servers
10,000,000    4629.6  13888.9    28  4 + cache (DB load 4028/s)
100,000,000  46296.3 138888.9   278  8 + sharding (writes 13889/s)

৫ · একটি অনুরোধের যাত্রা — সময় যায় কোথায়

সংখ্যার দ্বিতীয় দিক সময়। ব্যবহারকারী অ্যাপে একটি পণ্যের পাতা খুললেন; অনুরোধটি ফোন থেকে database পর্যন্ত গিয়ে ফেরে, আর প্রতিটি ধাপে কিছু মিলিসেকেন্ড যোগ হয়। ধরে নেওয়া মান: ফোন থেকে data centre পর্যন্ত একবার যাওয়া-আসা (RTT) ৪০ ms, cache-এ খোঁজা ১ ms, database query ২৫ ms. তথ্যটি cache-এ নেই (miss) — সবচেয়ে লম্বা পথ।

একই হিসাব এবার ক্যালকুলেটরে — cache-এ পেলে (hit) আর না পেলে (miss) মোট সময় কত, আর প্রতিটি অংশের ভাগ কত শতাংশ:

// Latency budget of ONE request. All times are ASSUMED round numbers (ms).
// Phone <-> data centre round trip time (RTT) = 40 ms; real values vary a lot.
const RTT = 40;
const DNS = 20, HANDSHAKE = 2 * RTT;          // TCP (1 RTT) + TLS 1.3 (1 RTT)
const parts = [
  ["DNS lookup", DNS],
  ["TCP + TLS 1.3 handshakes", HANDSHAKE],
  ["request + response travel", RTT],
  ["load balancer", 1],
  ["app server logic", 10],
  ["cache lookup", 1],
  ["DB query (only on a miss)", 25],
];

function budget(title, path) {
  const total = path.reduce((sum, [, ms]) => sum + ms, 0);
  console.log(`== ${title}: total ${total} ms ==`);
  for (const [name, ms] of path) {
    const pct = (100 * ms / total).toFixed(1);
    console.log(`  ${name.padEnd(27)}${String(ms).padStart(4)} ms ${pct.padStart(5)}%`);
  }
  return total;
}

const hit = budget("cache HIT", parts.slice(0, 6));
const miss = budget("cache MISS", parts);
const inside = (path) => path.slice(3).reduce((sum, [, ms]) => sum + ms, 0);
console.log(`inside the data centre: hit ${inside(parts.slice(0, 6))} ms, miss ${inside(parts)} ms`);
console.log(`reused connection (no DNS/TCP/TLS): hit ${hit - DNS - HANDSHAKE} ms, ` +
            `miss ${miss - DNS - HANDSHAKE} ms`);

== cache HIT: total 152 ms ==
  DNS lookup                   20 ms  13.2%
  TCP + TLS 1.3 handshakes     80 ms  52.6%
  request + response travel    40 ms  26.3%
  load balancer                 1 ms   0.7%
  app server logic             10 ms   6.6%
  cache lookup                  1 ms   0.7%
== cache MISS: total 177 ms ==
  DNS lookup                   20 ms  11.3%
  TCP + TLS 1.3 handshakes     80 ms  45.2%
  request + response travel    40 ms  22.6%
  load balancer                 1 ms   0.6%
  app server logic             10 ms   5.6%
  cache lookup                  1 ms   0.6%
  DB query (only on a miss)    25 ms  14.1%
inside the data centre: hit 12 ms, miss 37 ms
reused connection (no DNS/TCP/TLS): hit 52 ms, miss 77 ms

Cache-এর আসল লাভ — database-এর ভার

Cache-এর বড় জাদু অবশ্য সময়ে নয়, database-এর ভারে। ধরা যাক peak-এ সেকেন্ডে ২০,০০০টি read আসে, আর একটি database সেকেন্ডে ~৫,০০০টি query সামলায়। Cache-এর hit ratio (কত শতাংশ অনুরোধ cache-এই মেটে) যত বাড়ে, database-এ তত কম পৌঁছায়:

// How much read load still reaches the database at each cache hit ratio?
// ASSUMED round numbers: 20,000 reads/s at peak, one DB server ~5,000 queries/s,
// cache lookup ~1 ms, DB query ~25 ms (a miss pays both).
const READS = 20000, DB_CAP = 5000, CACHE_MS = 1, DB_MS = 25;

console.log("hit ratio  DB reads/s  DB servers  avg read time");
for (const h of [0, 0.5, 0.8, 0.9, 0.95, 0.99]) {
  const toDb = READS * (1 - h);                  // only misses reach the DB
  const servers = Math.ceil(toDb / DB_CAP);
  const avgMs = h * CACHE_MS + (1 - h) * (CACHE_MS + DB_MS);
  console.log(`${(h * 100).toFixed(0).padStart(8)}%` + toDb.toFixed(0).padStart(12) +
    String(servers).padStart(12) + avgMs.toFixed(2).padStart(12) + " ms");
}

// The other side of the coin: the cache dies while the DB is sized for 90% hits.
const planned = READS * (1 - 0.9);
console.log(`cache down: DB gets ${READS}/s instead of ${planned.toFixed(0)}/s ` +
            `= ${(READS / planned).toFixed(0)}x the planned load`);

hit ratio  DB reads/s  DB servers  avg read time
       0%       20000           4       26.00 ms
      50%       10000           2       13.50 ms
      80%        4000           1        6.00 ms
      90%        2000           1        3.50 ms
      95%        1000           1        2.25 ms
      99%         200           1        1.25 ms
cache down: DB gets 20000/s instead of 2000/s = 10x the planned load

৬ · “এই বাক্সটি মরলে কী হবে?” — single point of failure

System designer-এর সবচেয়ে কাজের অভ্যাস: ছবির প্রতিটি বাক্সে আঙুল রেখে জিজ্ঞেস করা, “এটি এই মুহূর্তে বন্ধ হলে কী হবে?” বড় আকারে বিকল হওয়া নিয়মিত ঘটনা — হাজারো যন্ত্রের মধ্যে প্রায় প্রতিদিনই কোনো disk বা power supply নষ্ট হয়। নিচে প্রতিটি ধাপে একটি করে বাক্স “মেরে” দেখা যাক।

৭ · System design-এর ইট — building block-গুলো এক নজরে

সেবা যত বড়ই হোক, ঘুরেফিরে কয়েকটি একই ধরনের ইট দিয়ে গড়া। প্রতিটির ভেতরের কৌশল পরের মডিউলগুলোর বিষয়; এখন শুধু চিনে রাখুন কে কী করে:

ছবিতে একটি অনুরোধের পথ মিলিয়ে দেখুন। ফোন DNS থেকে সুস্থ আর কাছের region-এর ঠিকানা পায়। ছবি আর CSS আসে CDN থেকে; CDN-এর কাছে না থাকলে সে object storage থেকে এনে রাখে। আসল অনুরোধ load balancer হয়ে যায় একটি app সার্ভারে; app আগে cache দেখে, না পেলে গ্রাহকের id দেখে ঠিক shard-এ যায়। খোঁজা যায় search-এ, ধীর কাজ queue-তে। আর monitoring সব স্তর থেকে তথ্য জোগাড় করে — কিছু ভাঙলে প্রথম খবর আসে সেখান থেকেই।

৮ · ভালো নকশার মাপকাঠি আর trade-off-এর মন

একটি নকশা ভালো না খারাপ, তা মাপা হয় কয়েকটি গুণ দিয়ে: scalability (ভার বাড়লে যন্ত্র যোগ করে সামলানো যায় কি না), availability (কত শতাংশ সময় চালু), latency (কত দ্রুত উত্তর, বিশেষ করে ধীরতম অনুরোধে), consistency (সবাই একই, হালনাগাদ ডেটা দেখেন কি না), durability (একবার “সেভ হয়েছে” বললে ডেটা আর হারায় না), খরচ, আর maintainability (বুঝতে, চালাতে আর বদলাতে সহজ কি না)। এগুলোকে বলে non-functional requirement; কোনটি কতটা দরকার, তা ঠিক হয় ব্যবসা থেকে — পর্ব ০২-এর বিষয়।

নিখুঁত নকশা বলে কিছু নেই। প্রতিটি সিদ্ধান্ত একটি সুবিধা কেনে, আর তার দাম দেয় অন্য কোথাও — একেই বলে trade-off. ভালো প্রকৌশলী “সেরা কোনটা?” জিজ্ঞেস করেন না; জিজ্ঞেস করেন, “এই পরিস্থিতিতে কোন দামটা দিতে রাজি?” তিনটি উদাহরণ:

তিনটির কোনোটিতেই সর্বজনীন “সঠিক উত্তর” নেই, আছে প্রেক্ষাপট: একই প্রশ্নের উত্তর খবরের সাইটে এক রকম, mobile banking সেবায় আরেক রকম। তাই প্রতিটি সিদ্ধান্তের পাশে তার কারণ আর দাম লিখে রাখা হয়।

৯ · System design কোথায় লাগে, আর এই কোর্স কীভাবে সাজানো

System design-এর দেখা পাবেন তিন জায়গায়:

• বিশ্ববিদ্যালয়ে: Software Architecture, Distributed Systems, Cloud Computing আর Web Engineering-এর মতো কোর্সে — সংজ্ঞা, তুলনা (vertical বনাম horizontal, SQL বনাম NoSQL), ছোট নকশা বা হিসাব হিসেবে।
• চাকরির ইন্টারভিউতে: backend, full-stack, SRE/DevOps আর অভিজ্ঞ পদে প্রায়ই প্রায় এক ঘণ্টার একটি খোলা প্রশ্ন — “একটি URL shortener নকশা করুন।” শুদ্ধ উত্তরের চেয়ে বেশি দেখা হয় চিন্তার ধারা: প্রশ্ন করে প্রয়োজন বের করা, হিসাব, trade-off-এর ব্যাখ্যা। কাঠামো পর্ব ০৬-এ, পূর্ণ অনুশীলন মডিউল ১০-এ।
• কাজের জায়গায়: বড় ফিচার বানানোর আগে দলগুলো একটি design doc লেখে — সমস্যা, বিকল্প, বেছে নেওয়া পথ, তার দাম আর ঝুঁকি; তারপর design review-তে সহকর্মীরা প্রশ্ন করেন। ভুল কাগজে ধরা পড়লে সবচেয়ে সস্তা।

কোর্সের মানচিত্র — ১০টি মডিউল, ৬৬টি পর্ব

পূর্বপ্রস্তুতি — কী জানা থাকলে সুবিধা

• নেটওয়ার্ক: DNS, TCP, HTTP আর TLS-এর মৌলিক ধারণা — কম্পিউটার নেটওয়ার্ক কোর্স, বিশেষ করে DNS, HTTP আর Web cache ও CDN. দরকারি অংশটুকু পর্ব ৭-এ সংক্ষেপে আবার দেখব।
• Database: টেবিল, SQL query, index আর transaction — DBMS ও SQL কোর্স, বিশেষ করে Index আর Transaction আর ACID.
• অপারেটিং সিস্টেম: process, thread, মেমরি আর disk-এর মোটা ধারণা — অপারেটিং সিস্টেম কোর্স, বিশেষ করে প্রসেস আর থ্রেড.
• প্রোগ্রামিং আর গণিত: যেকোনো ভাষায় ছোট প্রোগ্রাম পড়তে পারা, আর শতাংশ-গুণ-ভাগে স্বাচ্ছন্দ্য। সিমুলেটরগুলো JavaScript-এ, তবে বুঝতে JavaScript জানা জরুরি নয়।

১০ · AI-এর যুগে system design — সহকারী, বিচারক নয়

AI-এর কাছে একটি খাবার-ডেলিভারি অ্যাপের system design চাইলে কয়েক সেকেন্ডে সুন্দর উত্তর আসে — microservices, Kafka, Redis, Kubernetes, সবই আছে। উত্তরটি দেখতে নিখুঁত, কিন্তু প্রায়ই আপনার প্রয়োজনের সাথে মেলে না। AI-এর ভুলগুলো নির্দিষ্ট ধরনের, আর আসে আত্মবিশ্বাসী সুরে:

AI-এর নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• QPS, storage বা bandwidth-এর প্রতিটি হিসাব নিজে আবার করেছি, একক (bit-byte, সেকেন্ড-দিন) মিলিয়ে
• প্রতিটি বাক্সের পাশে লেখা আছে সে কোন সমস্যা সমাধান করে; কারণ নেই এমন বাক্স বাদ দিয়েছি
• প্রতিটি বাক্সের জন্য জিজ্ঞেস করেছি “এটি মরলে কী হবে?” — SPOF-এর তালিকা বানিয়েছি
• Consistency-র প্রতিটি দাবি পড়ে বুঝেছি সেটি ACID-এর অর্থে, না CAP-এর
• সেবার সীমা আর দাম অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি, লেখার তারিখসহ
• সম্ভব হলে ছোট load test বা এই কোর্সের মতো simulation চালিয়ে সংখ্যাগুলো মিলিয়েছি