একটি নকশা কীভাবে এগোয় — requirement থেকে API, data model আর deep dive

১ · ফাঁকা বোর্ডের সামনে — কেন একটি কাঠামো দরকার

ইন্টারভিউর ঘরে আপনাকে বলা হলো: “একটি পাবলিক পরীক্ষার ফল প্রকাশের ওয়েবসাইট নকশা করুন।” সামনে ফাঁকা হোয়াইটবোর্ড, হাতে মার্কার, সময় ৪৫ মিনিট। অনেকে তখন হয় চুপ করে জমে যান, নয়তো সঙ্গে সঙ্গে load balancer, Kafka, Redis আর microservices-এর বাক্স আঁকতে শুরু করেন। দুটোই বিপদ — প্রথমটিতে সময় যায়, দ্বিতীয়টিতে এমন প্রশ্নের উত্তর দেওয়া হয় যা কেউ জিজ্ঞেসই করেনি।

অভিজ্ঞ প্রকৌশলীদের কাছে নকশা একটি প্রক্রিয়া: কিছু প্রশ্ন, একটি নির্দিষ্ট ক্রমে — এই পর্বের বিষয় সেটাই। মডিউল ১-এর আগের পাঁচ পর্বে যা শিখেছেন — system design কেন, requirement আর trade-off, হিসাব, latency আর availability — সব এখানে এক সুতোয় গাঁথা হবে।

২ · ধাপ ১–৪: পরিধি, হিসাব, API আর data model

ধাপ ১ — পরিধি আর requirement: আগে প্রশ্ন

প্রথম কয়েক মিনিট প্রশ্ন করার জন্য। Functional requirement (FR) বলে সিস্টেম কী করবে — “roll নম্বর দিয়ে ফল দেখা যাবে।” Non-functional requirement (NFR) বলে কাজটি কতটা ভালোভাবে হবে — কত দ্রুত, কতজনের জন্য, কতটা নির্ভরযোগ্য, কতটা নিরাপদ। পর্ব ০২-এ দুটির পার্থক্য বিস্তারিত দেখেছেন। এখানে মনে রাখার মতো চারটি প্রশ্ন:

• ব্যবহারকারী কারা, কতজন? মানুষ, প্রতিষ্ঠান, নাকি অন্য সার্ভিস? সাধারণ দিনে আর ভিড়ের সময়ে কতজন?
• পড়া বেশি, না লেখা? প্রায় সবই পড়া (read-heavy) আর লেখাই বেশি (write-heavy) — দুটোর নকশা একেবারে আলাদা।
• কোনটা কোনোভাবেই চলবে না? ভুল তথ্য, নাকি কয়েক সেকেন্ড দেরি? একটি বাছতে হলে কোনটি?
• কী বাইরে থাকবে? “এবার পুনঃনিরীক্ষার আবেদন ধরছি না” — স্পষ্ট করে বলা পরিধিও একটি সিদ্ধান্ত।

ধাপ ২ — হিসাব: সংখ্যাই নকশার আকার ঠিক করে

পর্ব ০৩-এর back-of-the-envelope হিসাব এখানে কাজে লাগে। লক্ষ্য নিখুঁত সংখ্যা নয়, মাত্রা: প্রতি সেকেন্ডে ১০টি অনুরোধ, না ১০ হাজার? ১ GB ডেটা, না ১০০ TB? প্রথমটি হলে একটি সার্ভারেই চলে; দ্বিতীয়টি হলে ডেটা ভাগ করে বহু যন্ত্রে রাখতে হবে। তিনটি সংখ্যা প্রায় সবসময় বের করবেন — গড় আর সবচেয়ে ভিড়ের (peak) QPS, মোট storage, আর bandwidth. প্রতিটি অনুমান মুখে বলে নেবেন: “ধরে নিচ্ছি প্রতিজন দুবার দেখেন।”

ধাপ ৩ — API: রেস্তোরাঁর মেনু

রেস্তোরাঁয় আপনি মেনু দেখে অর্ডার দেন; রান্নাঘরে কে কী করছে, জানার দরকার পড়ে না। API (Application Programming Interface) হলো সিস্টেমের সেই মেনু — বাইরের ক্লায়েন্ট কী চাইতে পারে, কীভাবে চাইবে, কী ফেরত পাবে। এই ধাপে শুধু মূল দুই-চারটি endpoint লিখুন: HTTP method, path, request আর response-এর রূপ, ভুল হলে কোন status code. API পরের সব ধাপের চুক্তি; pagination, versioning আর idempotency-র খুঁটিনাটি আসবে পর্ব ০৮-এ (REST API নকশা)।

ধাপ ৪ — Data model: খোঁজার ধরন আগে, টেবিল পরে

মুদি দোকানের বাকির খাতার কথা ভাবুন। দোকানি পাতা সাজান ক্রেতার নাম ধরে, কারণ তিনি সবসময় নাম দিয়েই খোঁজেন — “রহিম সাহেবের বাকি কত?” তারিখ ধরে সাজালে প্রতিবার পুরো খাতা উল্টাতে হতো। Data model-এও তাই: আগে সত্তাগুলো (entity), তারপর সবচেয়ে জরুরি প্রশ্ন — access pattern: ডেটা কোন প্রশ্নে, কোন key দিয়ে, কত ঘনঘন পড়া বা লেখা হবে। সেখান থেকেই আসে key, index আর storage-এর ধরন। সম্পর্কযুক্ত ডেটা আর transaction-এর জন্য relational ডেটাবেস, শুধু key দিয়ে বিপুল পড়ার জন্য key-value store, বড় ফাইলের জন্য object storage — বিস্তারিত তুলনা পর্ব ১৯–২০-এ।

৩ · ধাপ ৫–৮: ছবি আঁকা, গভীরে নামা, ভাঙন খোঁজা আর গুছিয়ে শেষ

ধাপ ৫ — High-level design: বাক্স আর তীর

এবার ছবি। একটি অনুরোধ যে যে বাক্স পেরোয় — DNS, CDN, load balancer, অ্যাপ সার্ভার, cache, ডেটাবেস — সেগুলো আঁকুন, তীর দিয়ে জুড়ুন, তারপর একটি অনুরোধকে মুখে মুখে পুরো পথ হাঁটিয়ে আনুন। নিয়ম একটাই: প্রতিটি বাক্সের পেছনে একটি কারণ থাকবে — একটি requirement, বা ধাপ ২-এর একটি সংখ্যা। কারণ বলতে না পারলে বাক্সটি মুছে দিন; জটিলতা আসবে শুধু প্রয়োজনে।

ধাপ ৬ — Deep dive: যেখানে চাপ সবচেয়ে বেশি

সংখ্যাগুলো দেখলেই বোঝা যায় কোথায় চাপ জমবে — সেটিই bottleneck. এমন এক-দুটি অংশ বেছে গভীরে যান: ভিড় কীভাবে সামলাবেন (scaling), ডেটা কতটা মিলিয়ে রাখতে হবে (consistency), কোন অ্যালগরিদম লাগবে। ইন্টারভিউয়ার প্রায়ই নিজেই একটি অংশ দেখিয়ে দেন — “ধরুন সবাই একসাথে ঢুকল, তখন?”

ধাপ ৭ — Failure mode আর trade-off

প্রতিটি বাক্সে আঙুল রেখে জিজ্ঞেস করুন: “এটি বন্ধ হয়ে গেলে কী হবে?” যে অংশের মাত্র একটি কপি, সেটি বন্ধ হলে পুরো সিস্টেম বসে যায় — পর্ব ০৫-এর single point of failure. প্রতিটি failure mode-এর জন্য তিনটি কথা বলুন: কীভাবে টের পাবেন, ব্যবহারকারী কী দেখবেন, কীভাবে সামলাবেন। সাথে প্রতিটি বড় সিদ্ধান্তের trade-off স্পষ্ট করুন — “cache নিলাম, তাই কয়েক মিনিট পুরোনো তথ্য দেখানোর ঝুঁকি মেনে নিলাম।”

ধাপ ৮ — Wrap-up: নজরদারি, বৃদ্ধি আর পরের কাজ

শেষ কয়েক মিনিটে তিনটি কথা। এক, কোন সংখ্যার ওপর নজর রাখবেন — latency-র p99, error-এর হার, cache-এর hit ratio, ডেটাবেসের চাপ (observability নিয়ে পর্ব ৫০)। দুই, ব্যবহারকারী দশ গুণ হলে প্রথমে কোথায় ভাঙবে, তখন কী বদলাবেন। তিন, সময় পেলে পরের কোন কাজটি করতেন। শেষে এক মিনিটে পুরো নকশার সারাংশ।

৪ · পূর্ণ উদাহরণ — ফল প্রকাশের ওয়েবসাইট: পরিধি আর হিসাব

এবার আটটি ধাপ একটি বাস্তবধর্মী সমস্যায় চালিয়ে দেখা যাক। বড় পাবলিক পরীক্ষার ফল যেদিন প্রকাশ হয়, সেদিন লাখো পরীক্ষার্থী আর তাঁদের পরিবার প্রায় একই মুহূর্তে ফল দেখতে চান — ঈদের আগে অগ্রিম বাসের টিকিট বিক্রির প্রথম সকালের মতো, যখন সবাই একসাথে কাউন্টারে।

আগে পুরো পথ এক নজরে; প্রতিটি ধাপের বিস্তারিত পরের অংশগুলোতে।

ধাপ ১ বিস্তারিত — কী বানাচ্ছি, কী বানাচ্ছি না

ধাপ ২ বিস্তারিত — peak কত?

অনুমানগুলো আগে লিখে ফেলি। সবগুলোই ধরা যাক, বাস্তব কোনো পরীক্ষার তথ্য নয়:

• মোট পরীক্ষার্থী ২০ লাখ; তাঁদের ৬০%-এর ফল প্রথম ঘণ্টাতেই দেখা হয়।
• প্রতিটি ফল দুজন আলাদা যন্ত্রে দেখেন — পরীক্ষার্থী নিজে আর পরিবারের একজন।
• প্রতি দর্শক গড়ে ১.৫টি অনুরোধ পাঠান (কেউ কেউ refresh করেন); সাইট ধীর হলে ৪টি।
• প্রথম ঘণ্টার অনুরোধের ৪০% আসে প্রথম ১০ মিনিটে; সবচেয়ে ভিড়ের মিনিটে চাপ এই ১০ মিনিটের গড়ের ১.৫ গুণ।
• ফলের JSON উত্তর ২ KB; পাতার কাঠামো (HTML, CSS, JavaScript, লোগো) ১৫০ KB.

একই হিসাব ক্যালকুলেটরে — সাইট দ্রুত আর ধীর, সাথে bandwidth ও storage:

// Result day: back-of-the-envelope peak load. EVERY input is an assumption.
const examinees = 2000000;  // total examinees
const firstHour = 0.6;      // share whose result is checked in the first hour
const viewers   = 2;        // examinee + one family member/teacher, separate devices
const tenMin    = 0.4;      // share of the first hour's requests in the first 10 minutes
const peakX     = 1.5;      // busiest minute vs the 10-minute average
const resultKB  = 2;        // one JSON answer
const shellKB   = 150;      // page shell: HTML + CSS + JS + logo (first load)

const W = [5, 11, 11, 7, 14, 8, 12];                      // column widths
const row = (c) => c.map((x, i) => (i ? String(x).padStart(W[i]) : String(x).padEnd(W[i])))
  .join("");
const lookups = examinees * firstHour * viewers;          // viewers in hour 1
console.log("lookups in hour 1: " + lookups.toLocaleString("en-US"));
console.log(row(["site", "req/viewer", "req/hour", "avg/s", "10-min avg/s", "peak/s", "API Mbit/s"]));
for (const [site, perViewer] of [["fast", 1.5], ["slow", 4]]) {
  const reqHour = lookups * perViewer;
  const avg10 = reqHour * tenMin / 600;                  // 10 minutes = 600 s
  const peak = avg10 * peakX;
  const mbps = peak * resultKB * 8 / 1000;               // KB/s -> Mbit/s
  console.log(row([site, perViewer, reqHour.toLocaleString("en-US"),
    Math.round(reqHour / 3600), Math.round(avg10), Math.round(peak), mbps.toFixed(1)]));
}
const shellPeak = lookups * tenMin / 600 * peakX;         // new viewers per second at peak
const gbps = shellPeak * shellKB * 8 / 1e6;               // KB/s -> Gbit/s
console.log("page shell from origin, no CDN: " + gbps.toFixed(2) + " Gbit/s");
console.log("all results stored (1 KB/row): " + (examinees / 1e6).toFixed(1) + " GB");

lookups in hour 1: 2,400,000
site  req/viewer   req/hour  avg/s  10-min avg/s  peak/s  API Mbit/s
fast         1.5  3,600,000   1000          2400    3600        57.6
slow           4  9,600,000   2667          6400    9600       153.6
page shell from origin, no CDN: 2.88 Gbit/s
all results stored (1 KB/row): 2.0 GB

৫ · উদাহরণ চলছে — API, data model আর চূড়ান্ত নকশার ছবি

ধাপ ৩ — API: একটিই মূল endpoint

সরল রাখুন। সাধারণ মানুষের কাজ একটিই — নিজের ফল দেখা। তাই একটি endpoint, যার path-এই বছর, বোর্ড আর roll থাকে: GET /v1/results/{year}/{board}/{roll}.

GET /v1/results/2026/north/104521 HTTP/1.1
Host: results.example.org
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: public, max-age=300

{
  "board": "north", "year": 2026, "roll": 104521,
  "name": "Nusrat Jahan", "gpa": 5.00,
  "grades": { "bangla": "A+", "math": "A+" }
}

GET কেন? শুধু পড়া হচ্ছে; GET নিরাপদ আর idempotent, আর HTTP-র নিয়মে এর উত্তর cache করা যায় — তাই CDN আর ব্রাউজার নির্ভয়ে কপি রাখতে পারে, retry-ও নিরাপদ। Path-এ বছর আর বোর্ড কেন? একই roll ভিন্ন বোর্ডে বা বছরে থাকতে পারে। রেজিস্ট্রেশন নম্বরও চাইব? চাইলে গণহারে অন্যের ফল টেনে নেওয়া কঠিন হয়, কিন্তু ব্যবহারকারীর ঝামেলা বাড়ে — একটি trade-off. ফল আপলোডের ভেতরের API সাধারণ মানুষের জন্য খোলা নয়।

ধাপ ৪ — Data model: একটি টেবিল, একটি key

সত্তা মাত্র কয়েকটি: পরীক্ষা (বছর), বোর্ড, আর পরীক্ষার্থীর ফল — roll, রেজিস্ট্রেশন নম্বর, নাম, GPA আর বিষয়ভিত্তিক grade. Access pattern আরও সরল: প্রকাশের দিনের প্রায় সব পড়া একটিই প্রশ্ন — “এই বোর্ড, এই বছর, এই roll-এর ফল কী?” লেখা হয় একবার, প্রকাশের আগে, একসাথে। তাই key হবে তিনটি কলাম মিলিয়ে একটি composite key.

নিচের লাইভ SQL এডিটরে টেবিলটি বানিয়ে দেখুন ডেটাবেস কোন পথে খোঁজে। এটি একটি single-node SQLite ডেমো: index আর query plan দেখায়; replication, cache বা বহু যন্ত্রে ভাগ করা ডেটাবেস দেখায় না। SQLite-এর EXPLAIN QUERY PLAN query না চালিয়েই পথটি বলে দেয়।

-- Single-node SQLite demo: one table, one main access pattern.
CREATE TABLE results (
  board  TEXT    NOT NULL,          -- fictional board code
  year   INTEGER NOT NULL,
  roll   INTEGER NOT NULL,
  reg_no TEXT    NOT NULL,
  name   TEXT    NOT NULL,
  gpa    REAL    NOT NULL,
  grades TEXT    NOT NULL,          -- JSON: subject -> grade
  PRIMARY KEY (board, year, roll)   -- the lookup key
) WITHOUT ROWID;

INSERT INTO results VALUES
 ('north', 2026, 104521, 'R-7781', 'Nusrat Jahan', 5.00, '{"bangla":"A+","math":"A+"}'),
 ('north', 2026, 104522, 'R-7782', 'Rafi Ahmed',   4.83, '{"bangla":"A","math":"A+"}'),
 ('south', 2026, 104521, 'R-9120', 'Tanvir Hasan', 4.50, '{"bangla":"A","math":"A-"}'),
 ('north', 2025, 104521, 'R-6603', 'Mim Akter',    4.92, '{"bangla":"A+","math":"A"}');

EXPLAIN QUERY PLAN
SELECT name, gpa, grades FROM results
WHERE board = 'north' AND year = 2026 AND roll = 104521;

EXPLAIN QUERY PLAN
SELECT name, gpa FROM results WHERE roll = 104521;

SELECT board, year, roll, name, gpa FROM results WHERE roll = 104521;

ধাপ ৫ — চূড়ান্ত high-level design

এবার পুরো ছবি; প্রতিটি বাক্স কোনো সংখ্যা বা requirement-এর জবাব:

একজন অভিভাবকের অনুরোধ ধরে পথটি হাঁটি। DNS নাম থেকে কাছের CDN edge-এর ঠিকানা দিল; পাতার কাঠামো এল CDN থেকেই, মূল সার্ভার (origin) জানলই না — CDN-এর খুঁটিনাটি পর্ব ১৭-এ। ফলের অনুরোধ CDN-এ না মিললে rate limiter আর load balancer পেরিয়ে যেকোনো একটি stateless API সার্ভারে — কেউ কারও আলাদা তথ্য মনে রাখে না, তাই ভিড় বাড়লে শুধু সার্ভার বাড়ালেই হয়। API আগে cache-এ খোঁজে; আগে থেকে ভরা বলে প্রায় সবসময় পায়, না পেলে read replica থেকে পড়ে cache-এ রাখে। লেখা হয় শুধু primary-তে, প্রকাশের আগে একটি job-এর মাধ্যমে, আর replication-এ কপিগুলো হালনাগাদ হয়। বাঁ দিকের ভাঙা বাক্সটি বিকল্প: আগে থেকে বানানো ফলের ফাইল object storage-এ, যা দরকারে CDN সরাসরি দিতে পারে।

৬ · Deep dive — প্রকাশের মুহূর্তের thundering herd

কোন অংশে গভীরে যাবেন? সংখ্যাই বলে দেয়: দুপুর ২টা ০০ মিনিট ০০ সেকেন্ড। হাজারো মানুষ পাতা খুলে বসে আছেন; ঘড়ির কাঁটা ঘুরতেই সবাই একসাথে চাপ দেন, অথচ cache তখনো ঠান্ডা — এক মিনিট আগেও ফল প্রকাশিতই ছিল না। বিপুল অনুরোধ cache-এ না পেয়ে একসাথে ডেটাবেসের দরজায় — একে বলে thundering herd, বুনো পশুর পালের হঠাৎ দৌড়; cache-এর প্রসঙ্গে আরেক নাম cache stampede.

প্রথম সেকেন্ডটি ধীরে ধীরে দেখুন। ধরা যাক প্রথম সেকেন্ডে ৪,০০০ অনুরোধ আসে ২,৫০০টি আলাদা roll-এর জন্য, আর ডেটাবেস নিরাপদে সেকেন্ডে ১,০০০টি query সামলায়।

এবার মিনিট ধরে দেখা যাক। অংশ ৪-এর অনুমানে প্রথম ১০ মিনিটে প্রায় ৪.৮ লাখ পরীক্ষার্থী প্রথমবার ফল দেখেন, শুরুর দিকে বেশি। মডেল সরল: পরীক্ষার্থী যে মিনিটে দেখেন, পরিবারের সদস্য দেখেন তার পরের মিনিটে; cache-এ একবার আসা roll আর হারায় না। পরিস্থিতি তিনটি: cache ঠান্ডা, আগে থেকে ভরা, আর ভরা cache মিনিট ৩-এ হঠাৎ খালি।

// Result day, first 10 minutes: database queries/s behind a cache.
// Same assumptions as the estimate above; none of this is real board data.
const firstTen  = 2000000 * 0.6 * 0.4;      // examinees whose first lookup is in minutes 1-10
const share     = [16, 14, 12, 11, 10, 9, 8, 7, 7, 6]; // % of them per minute (front-loaded)
const perViewer = 1.5;                      // requests per viewer (lookup + some refresh)
const DB_SAFE   = 1000;                     // queries/s the database serves safely (assumed)
const fresh = share.map((s) => firstTen * s / 100 / 60);  // first-time rolls per second

// The examinee looks in minute m; a family member looks at the same roll in minute m + 1.
// Cache-aside: only the FIRST request for a roll misses; later ones hit (results never change).
function dbLoad(m, mode) {
  if (mode === "warm") return 0;                 // all results loaded before the release
  if (mode === "restart" && m < 2) return 0;     // warm cache until minute 3 begins
  if (mode === "restart" && m === 2) return fresh[2] + fresh[1]; // emptied: family rolls miss
  return fresh[m];                               // cold (or emptied) cache: new rolls miss
}
const W = [3, 7, 10, 12, 11, 16];
const row = (c) => c.map((x, i) => String(x).padStart(W[i])).join("");
const flag = (q) => Math.round(q) + (q > DB_SAFE ? " OVER" : "");
console.log("database serves " + DB_SAFE + " queries/s safely (assumed)");
console.log(row(["min", "req/s", "cold hit", "cold DB/s", "warm DB/s", "restart@3 DB/s"]));
for (let m = 0; m < 10; m++) {
  const rps = perViewer * fresh[m] + (m > 0 ? perViewer * fresh[m - 1] : 0);
  const cold = dbLoad(m, "cold");
  console.log(row([m + 1, Math.round(rps), (100 * (1 - cold / rps)).toFixed(1) + "%",
    flag(cold), dbLoad(m, "warm"), flag(dbLoad(m, "restart"))]));
}

database serves 1000 queries/s safely (assumed)
min  req/s  cold hit   cold DB/s  warm DB/s  restart@3 DB/s
  1   1920     33.3%   1280 OVER          0               0
  2   3600     68.9%   1120 OVER          0               0
  3   3120     69.2%         960          0       2080 OVER
  4   2760     68.1%         880          0             880
  5   2520     68.3%         800          0             800
  6   2280     68.4%         720          0             720
  7   2040     68.6%         640          0             640
  8   1800     68.9%         560          0             560
  9   1680     66.7%         560          0             560
 10   1560     69.2%         480          0             480

বড় trade-off — আগে থেকে বানানো static ফাইল, নাকি dynamic API?

আরেক পথ: প্রকাশের আগেই প্রতিটি ফলের একটি ছোট JSON বা HTML ফাইল বানিয়ে object storage-এ রাখা, যা CDN সরাসরি দেবে — static pre-generation. তখন প্রকাশের মুহূর্তে ডেটাবেস বা API প্রায় লাগেই না। তুলনা:

আমাদের সিদ্ধান্ত: মূল পথ dynamic, কারণ সংশোধন আর প্রকাশের মুহূর্ত নিয়ন্ত্রণ সহজ; CDN ফলের উত্তর কয়েক মিনিট রাখবে, আর static ফাইলের পথ থাকবে জরুরি বিকল্প হিসেবে। উল্টো সিদ্ধান্তও যুক্তিসংগত — শুধু-পড়ার, আগে থেকে জানা ভিড়ে “সবচেয়ে সরল যা কাজ করে” প্রায়ই static ফাইলই। ইন্টারভিউতে দেখা হয়, দুটোর দাম আপনি জানেন কি না।

৭ · কী ভাঙতে পারে — failure mode, trade-off আর wrap-up

ছবি ৬.১-এর প্রতিটি বাক্সে একই প্রশ্ন: “এটি ভাঙলে কী হবে?” প্রকাশের দিনের প্রধান failure mode আর তাদের জবাব:

এবার সবচেয়ে ভয়ের পরিস্থিতি: আগে ভরা cache ঠিক ভিড়ের মধ্যে, মিনিট ৩-এ, হঠাৎ খালি। সংখ্যাগুলো অংশ ৬-এর simulator থেকে।

ধাপ ৮ — Wrap-up: কী মাপবেন, পরে কী বদলাবেন

প্রকাশের দিন নিচের সংখ্যাগুলো একটি dashboard-এ পাশাপাশি থাকবে। সতর্কসংকেতের মানগুলো উদাহরণ; আসল মান ঠিক হবে নিজের load test দেখে।

বৃদ্ধি আর পরের কাজ: পরীক্ষার্থী দ্বিগুণ হলে peak-ও প্রায় দ্বিগুণ — API stateless আর ডেটা ছোট, তাই সার্ভার আর cache বাড়ানো সহজ। পরের কাজ: এক সপ্তাহ আগে peak-এর দ্বিগুণ চাপে load test, তার মধ্যেই একটি cache node বন্ধ করে দেখা, আর একটি অপেক্ষা-কক্ষের পাতা। সারাংশ: “জানা ভিড়, ছোট ডেটা — তাই CDN, আগে ভরা cache আর আড়ালে রাখা ডেটাবেস।”

৮ · ইন্টারভিউর ৪৫ মিনিট আর বাস্তবের design doc

সময় ভাগ — একটি সাধারণ ছক

প্রায় ৪৫ মিনিটের ইন্টারভিউয়ে সময় মোটামুটি এভাবে ভাগ করা যায়। এটি ছক, নিয়ম নয় — প্রতিষ্ঠান, পদ আর ইন্টারভিউয়ারভেদে বদলায়; কেউ হিসাব চান না, কেউ শুরু থেকেই একটি অংশের গভীরে নেন। ঘড়ি আর ইন্টারভিউয়ারের ইঙ্গিত, দুটোই খেয়াল রাখুন। পূর্ণ case study আসবে পর্ব ৫৪–৬১-এ, আর ঘড়ি ধরে mock interview পর্ব ৬৬-এ।

অফিসে একই আট ধাপ — design doc, RFC আর ADR

বাস্তব কাজে এই আট ধাপ লেখা হয় একটি design doc-এ — প্রেক্ষাপট, লক্ষ্য আর যা লক্ষ্য নয় (non-goals), প্রস্তাবিত নকশা, বিকল্প, ঝুঁকি আর monitoring. লেখাটি সহকর্মীদের কাছে যায়; অনেক দল একে বলে RFC-ধাঁচের পর্যালোচনা: মন্তব্য, আপত্তি, সংশোধন, তারপর সিদ্ধান্ত। আর প্রতিটি বড় সিদ্ধান্ত লেখা থাকে একটি ADR-এ (পর্ব ০২): প্রেক্ষাপট, সিদ্ধান্ত, পরিণতি।

কথা বলার কৌশল

• মুখে ভাবুন। চুপচাপ আঁকলে ইন্টারভিউয়ার আপনার যুক্তি দেখতে পান না; মুখে বললে ভুল পথেও তিনি শুধরে দিতে পারেন।
• অনুমান স্পষ্ট করুন। “ধরে নিচ্ছি ফল প্রকাশের পর বদলায় না” — এক বাক্যেই পুরো cache-নীতির ভিত্তি।
• গভীরে নামার আগে পুরো ছবি। আগে সব বাক্স, তারপর একটির ভেতর।
• মতামত চান। “এখানে দ্রুততার চেয়ে নির্ভুলতাকে প্রাধান্য দিচ্ছি — আপনি কি অন্যভাবে দেখছেন?” এটা সহযোগিতার চিহ্ন, দুর্বলতা নয়।
• মাঝে মাঝে সারাংশ। প্রতি ধাপ শেষে এক বাক্যে কী ঠিক হলো।

সাধারণ ভুল

৯ · AI-এর যুগে system design — খসড়া AI-র, যাচাই আপনার

AI-এর কাছে ফল প্রকাশের সাইটের নকশা চাইলে কয়েক সেকেন্ডে সুন্দর খসড়া আসে — বাক্স, তীর, প্রযুক্তির নাম। কিন্তু কিছু চেনা ভুল বারবার দেখা যায়, আর সেগুলো ধরার দায়িত্ব আপনার:

AI-এর নকশা গ্রহণের আগে — চেকলিস্ট

• প্রতিটি বাক্সের পেছনে একটি requirement বা একটি সংখ্যা খুঁজে পেয়েছি
• সব হিসাব নিজে বা স্ক্রিপ্টে আবার করেছি, একক মিলিয়ে
• প্রতিটি অংশ একবার করে বন্ধ ধরে failure-mode review করেছি
• “consistency” কোন অর্থে — ACID না CAP — নিশ্চিত হয়েছি
• পণ্যের সীমা আর দাম অফিশিয়াল ডকুমেন্টেশনে মিলিয়েছি
• সম্ভব হলে ছোট load test বা simulation চালিয়ে দেখেছি