Back-of-the-envelope হিসাব — QPS, storage, bandwidth আর latency-র সংখ্যা

১ · নকশার আগে সংখ্যা — খামের পেছনের হিসাব কেন

ধরুন একটি দল ছবি শেয়ারিং অ্যাপ বানাবে। একজন বললেন, “সব ছবি একটি ভালো সার্ভারের disk-এ রাখলেই চলবে।” আরেকজন বললেন, “শুরু থেকেই দশটি data center লাগবে।” তর্ক চলতে পারে ঘণ্টার পর ঘণ্টা — অথচ পাঁচ মিনিটের একটি হিসাব মীমাংসা করে দেয়। দিনে ২০ লাখ ছবি, প্রতিটি গড়ে ২ MB হলে প্রতিদিন নতুন ডেটা ৪ TB, বছরে প্রায় ১.৫ PB — ১০^১৫ byte-এর মাত্রায়। একটি সার্ভারে এটা ধরে না। আবার ব্যবহারকারী মাত্র কয়েক হাজার হলে দশটি data center নিছক অপচয়।

এই ধরনের দ্রুত, মোটামুটি হিসাবকে বলে back-of-the-envelope estimation — যেন চায়ের দোকানে বসে খামের পেছনে কলম দিয়ে করা হিসাব। এর তিনটি কাজ:

• সম্ভব কি না (feasibility): নকশাটি আদৌ দাঁড়ায় কি না — যেমন বছরে ১.৫ PB একটি মেশিনে ধরে কি না।
• আকার ঠিক করা (sizing): কতগুলো সার্ভার, কত TB disk, কত Gbit/s network — আর খরচ কোন মাত্রার।
• দুর্বল জায়গা আগেভাগে খোঁজা: কোন resource আগে ফুরাবে, সেই bottleneck চেনা। ছবির অ্যাপে সেটি বাইরে পাঠানো ডেটা, URL shortener-এ পড়ার (read) ভিড়, chat-এ লেখার (write) চাপ — তাই তিনটির নকশা তিন দিকে যায়।

Requirement (পর্ব ২) জানায় কত ব্যবহারকারী, কত দ্রুত উত্তর চাই, কত দিন ডেটা রাখতে হবে; estimation সেগুলোকে সংখ্যায় বদলায়। পূর্ণ নকশার পথ আসবে পর্ব ৬-এ; আজ শুধু সংখ্যার অংশ, এই ছয় ধাপে:

২ · সংখ্যার ভাষা — power of 10, power of 2, bit আর byte

System design-এর সংখ্যাগুলো বিশাল — হাজার, লাখ, কোটি, তারপর আরও বড়। এগুলো সামলানোর সহজ উপায় হলো ১০-এর ঘাতে (power of 10) লেখা: ৩ কোটি = ৩ × ১০^৭। ইংরেজি এককের নাম তিন শূন্য পরপর বাড়ে, আর আমাদের লাখ-কোটি বাড়ে অন্য ছন্দে — তাই দুটির একটি সেতু মনে রাখা কাজের:

Bit আর byte — ৮ গুণের ফাঁদ। ৮টি bit মিলে একটি byte. ফাইল, disk আর memory মাপা হয় byte-এ, লেখা হয় বড় হাতের B দিয়ে, যেমন MB বা GB-তে। কিন্তু network-এর গতি মাপা হয় bit-এ, ছোট হাতের b দিয়ে — Mbps বা Mbit/s মানে প্রতি সেকেন্ডে মেগাবিট। তাই ১০০ Mbit/s ইন্টারনেট লাইনে সর্বোচ্চ ১২.৫ MB/s নামে, ১০০ MB/s নয়। ২০ Mbit/s লাইনে ১ GB-এর একটি ফাইল নামাতে লাগে ৮,০০০ Mbit ÷ ২০ = ৪০০ সেকেন্ড, প্রায় ৭ মিনিট — ৫০ সেকেন্ড নয়।

KB নাকি KiB? Computer memory স্বাভাবিকভাবে ২-এর ঘাতে বাড়ে, তাই বহু বছর “1 KB” বলতে কখনো ১,০০০ আর কখনো ১,০২৪ byte বোঝানো হতো। বিভ্রান্তি দূর করতে IEC (International Electrotechnical Commission) ১৯৯৮ সালে আলাদা নাম চালু করে — binary prefix: KiB (kibibyte) = ২^১০ = ১,০২৪ byte, MiB = ২^২০, GiB = ২^৩০। আর KB, MB, GB থাকল দশমিক অর্থে: ১০^৩, ১০^৬, ১০^৯। বাস্তবে disk নির্মাতা আর network দশমিক একক ব্যবহার করে, RAM-এর আকার আসলে binary (১৬ GB লেখা RAM আসলে ১৬ GiB), আর অপারেটিং সিস্টেমভেদে দেখানোর নিয়ম আলাদা।

দুটির ফারাক কত? k-তম prefix-এ binary মান ২^১০k, দশমিক মান ১০^৩k, তাই অনুপাত (১,০২৪ ÷ ১,০০০)^k, অর্থাৎ ১.০২৪-এর k-তম ঘাত। ফারাক তাই প্রতি ধাপে মোটামুটি ২.৪% করে বাড়ে (আসলে গুণ হয়)। নিচের কোড হিসাবটি নিজে করে দেখায়:

// Decimal (SI) prefixes vs binary (IEC) prefixes: how far apart do they drift?
const pairs = [["KB", "KiB"], ["MB", "MiB"], ["GB", "GiB"], ["TB", "TiB"], ["PB", "PiB"]];
console.log("pair        decimal  binary (bytes)       binary is bigger by");
pairs.forEach(([d, b], i) => {
  const k = i + 1;                       // 1 = kilo, 2 = mega, 3 = giga ...
  const dec = 10 ** (3 * k), bin = 2 ** (10 * k);
  const err = (bin / dec - 1) * 100;     // equals (1.024^k - 1) * 100
  console.log((d + " vs " + b).padEnd(12) + ("10^" + 3 * k).padEnd(9) +
              String(bin).padEnd(21) + err.toFixed(1) + "%");
});
const disk = 1e12;                       // a "1 TB" disk, as the maker counts it
console.log("A 1 TB disk = " + (disk / 2 ** 30).toFixed(1) + " GiB (a GiB-based display shows ~" +
            Math.floor(disk / 2 ** 30) + ")");
console.log("A 100 Mbit/s link carries at most " + 100e6 / 8 / 1e6 + " MB/s (8 bits = 1 byte)");
console.log("1 PB vs 1 PiB differ by " + ((2 ** 50 - 1e15) / 1e12).toFixed(0) + " TB");

pair        decimal  binary (bytes)       binary is bigger by
KB vs KiB   10^3     1024                 2.4%
MB vs MiB   10^6     1048576              4.9%
GB vs GiB   10^9     1073741824           7.4%
TB vs TiB   10^12    1099511627776        10.0%
PB vs PiB   10^15    1125899906842624     12.6%
A 1 TB disk = 931.3 GiB (a GiB-based display shows ~931)
A 100 Mbit/s link carries at most 12.5 MB/s (8 bits = 1 byte)
1 PB vs 1 PiB differ by 126 TB

৩ · সময়ের হিসাব আর এক significant figure

QPS (queries per second, প্রতি সেকেন্ডে অনুরোধ) বের করতে প্রায় সবসময় একটি ভাগ লাগে: দিনের মোট অনুরোধ ÷ এক দিনের সেকেন্ড। এক দিনে ২৪ × ৬০ × ৬০ = ৮৬,৪০০ সেকেন্ড, যা প্রায় ১০^৫ — প্রায় এক লাখ। এখান থেকে আমাদের জন্য চমৎকার একটি মনে রাখার কৌশল:

১০^৫ দিয়ে ভাগ করলে উত্তর আসল মানের ৮৬.৪% আসে, অর্থাৎ প্রায় ১৪% কম। মাথায় হিসাবের জন্য এটুকু চলে; চূড়ান্ত সংখ্যায় ৮৬,৪০০ ব্যবহার করুন, অথবা ১০^৫-এর উত্তরকে ১.১৬ দিয়ে গুণ করুন। বড় সময়ের জন্য:

এক significant figure আর ১০-এর ঘাতে গুণ

মাথায় বড় গুণ করার কৌশল: প্রতিটি সংখ্যাকে a × ১০ⁿ রূপে লিখুন, a-কে এক বা দুই significant figure-এ গোল করুন, তারপর a-গুলো গুণ করুন আর ঘাতগুলো যোগ করুন। যেমন, দিনে ৪ TB নতুন ছবি হলে বছরে কত?

ঠিক উত্তর ১.৪৬ PB — ৩৬৫-কে ৪০০ ধরায় আমাদের উত্তর প্রায় ১০% বেশি। এক significant figure-এ গোল করলে একটি সংখ্যায় সর্বোচ্চ প্রায় ৩৩% ভুল হতে পারে (যেমন ১.৫ → ২)। কয়েকটি সংখ্যার কোনোটি ওপরে, কোনোটি নিচে গোল করলে ভুলগুলো অনেকটা কাটাকাটি হয়; সব একদিকে গোল করলে জমে যায় — তিনটিকেই ৩৩% বাড়ালে গুণফল (৪/৩)^৩ ≈ ২.৪ গুণ বড় হয়। তখনো এক মাত্রার ভেতরে, কিন্তু সতর্ক থাকুন।

৪ · Latency-র মই — কোন কাজে মোটামুটি কত সময়

Storage আর bandwidth-এর পাশাপাশি তৃতীয় যে সংখ্যা নকশা বদলে দেয়, তা হলো latency — একটি কাজ শুরু থেকে শেষ হতে কত সময় লাগে। মানগুলো মুখস্থ নয়, মাত্রা হিসেবে মনে রাখুন; যন্ত্র, প্রজন্ম আর দূরত্বভেদে বদলায় বলে পরিসর দেওয়া হলো। শেষ কলামে সব সময়কে ১০০ কোটি গুণ বড় করে মানুষের মাপে আনা হয়েছে।

Memory-র দিকটা — RAM কেন cache-এর চেয়ে ধীর, আর locality কেন কাজ করে — বিস্তারিত আছে Computer Architecture কোর্সের মেমরি হায়ারার্কি পর্বে। System design-এর জন্য এই তালিকা থেকে তিনটি কাজের উপসংহার বেরোয়:

• Memory থেকে পড়া disk বা network-এর চেয়ে অন্তত হাজার গুণ সস্তা। এজন্যই cache: যা বারবার লাগে, তার কপি RAM-এ।
• একটি hard disk সেকেন্ডে মাত্র ~১০০–২০০টি random read পারে (১ ÷ ১০ ms = ১০০, ১ ÷ ৫ ms = ২০০)। এই মাপের নাম IOPS. হাজার হাজার random read চাইলে SSD বা memory লাগবে।
• পরপর হওয়া network call গুনুন। একই data center-এ ১০০টি call একটির পর একটি হলে শুধু round trip-এই ৫০ ms; মহাদেশ পেরোনো ৬টি হলে ৯০০ ms — পাতা খুলতেই প্রায় এক সেকেন্ড।

আলোর গতি — যে সীমা কোনো প্রকৌশলে কমে না

মহাদেশ পেরোনো latency কেন এত বেশি, আর কেন কমানো যায় না? Optical fiber-এর ভেতরে আলো চলে শূন্যস্থানে আলোর গতির প্রায় দুই-তৃতীয়াংশে, প্রায় ২ × ১০^৫ km/s — অর্থাৎ প্রতি ১,০০০ km-এ এক দিকে প্রায় ৫ ms. ঢাকা থেকে লন্ডনের সরাসরি দূরত্ব প্রায় ৮,০০০ km. তাই round trip-এর তাত্ত্বিক সর্বনিম্ন মান:

বাস্তবে cable সোজা পথে যায় না, পথে router আর অপেক্ষা যোগ হয়, তাই মাপা মান বেশ বেশি। CPU যত দ্রুতই হোক, এই ৮০ ms কমবে না — উপায় একটাই, ডেটা ব্যবহারকারীর কাছে রাখা। এখান থেকেই CDN আর edge (পর্ব ১৭), আর একাধিক region-এ সিস্টেম চালানো (পর্ব ৫১)। Latency, throughput আর percentile-এর পূর্ণ আলোচনা পরের পর্বে, পর্ব ৪-এ।

৫ · ছয়টি সূত্র — অনুরোধ থেকে সার্ভার পর্যন্ত

এবার হাতিয়ারগুলো এক জায়গায়। প্রায় প্রতিটি estimation এই ছয়টি সূত্রের কোনো মিশ্রণ। প্রতিটির input আসে requirement থেকে, অথবা “ধরা যাক” বলে স্পষ্ট লেখা হয়।

Storage-এর সূত্রটি মুদি দোকানের বাকির খাতার মতো: প্রতিদিন কয়েক পাতা ভরে, খাতা ফুরালে নতুন খাতা। আগুন বা চুরির ভয়ে দোকানি যদি প্রতিটি পাতার ফটোকপি আরও দুই জায়গায় রাখেন, কাগজ লাগে তিন গুণ — এই ফটোকপিই replication.

নিচের calculator ছয়টি সূত্র একসাথে চালায়। ধরে নেওয়া মানগুলো URL shortener-এর — যে উদাহরণ পরের অংশে ধাপে ধাপে করব। মান বদলে নিজের কোনো অ্যাপের হিসাব করে দেখুন।

// Back-of-the-envelope calculator. Every input is an ASSUMPTION: change it and run again.
const A = {
  name: "URL shortener",
  writesPerDay: 10e6,     // new short URLs per day
  readsPerDay: 1000e6,    // redirects per day (read:write = 100:1)
  recordBytes: 500,       // one stored record, incl. metadata
  responseBytes: 500,     // bytes sent back for one read
  peakFactor: 3,          // busiest second / average second
  years: 5, replication: 3,
  serverCapacity: 2000,   // req/s one server handled in a load test
  targetUtil: 0.6,        // run servers at 60% of that at peak
};
const DAY = 86400;
function si(x, unit) {    // 46296296 -> "46.3 Mbit/s" (powers of 10)
  const p = ["", "K", "M", "G", "T", "P", "E"]; let i = 0;
  while (x >= 1000 && i < p.length - 1) { x /= 1000; i++; }
  return (x >= 100 ? x.toFixed(0) : x >= 10 ? x.toFixed(1) : x.toFixed(2)) + " " + p[i] + unit;
}
const wQps = A.writesPerDay / DAY, rQps = A.readsPerDay / DAY;
const peak = (wQps + rQps) * A.peakFactor;
const perDay = A.writesPerDay * A.recordBytes;            // raw bytes per day
const perYear = perDay * 365 * A.replication;             // with all copies
const egress = rQps * A.responseBytes;                    // bytes per second
const servers = Math.ceil(peak / (A.serverCapacity * A.targetUtil));
console.log("Scenario: " + A.name + "  (every input is an assumption)");
console.log("avg QPS      write " + wQps.toFixed(1) + ", read " + rQps.toFixed(0));
console.log("peak QPS     " + peak.toFixed(0) + "  (x" + A.peakFactor + ")");
console.log("new data     " + si(perDay, "B") + "/day raw, " + si(perYear, "B") + "/year with x" + A.replication);
console.log(("in " + A.years + " yr").padEnd(13) + si(perYear * A.years, "B") + "  (x" + A.replication + ", before indexes)");
console.log("egress       avg " + si(egress * 8, "bit/s") + ", peak " + si(egress * 8 * A.peakFactor, "bit/s"));
console.log("servers      " + servers + " at peak, then add 1-2 spares");

Scenario: URL shortener  (every input is an assumption)
avg QPS      write 115.7, read 11574
peak QPS     35069  (x3)
new data     5.00 GB/day raw, 5.47 TB/year with x3
in 5 yr      27.4 TB  (x3, before indexes)
egress       avg 46.3 Mbit/s, peak 139 Mbit/s
servers      30 at peak, then add 1-2 spares

৬ · উদাহরণ ক — URL shortener, ধাপে ধাপে

URL shortener লম্বা একটি link-কে ছোট একটি code-এ বদলায় (যেমন s.example/x7Kp2Qa), আর কেউ ছোট link-এ গেলে তাঁকে আসল ঠিকানায় পাঠিয়ে (redirect) দেয়। পুরো নকশা আসবে পর্ব ৫৪-এ; এখানে শুধু সংখ্যা। ধরা যাক (সব মান কাল্পনিক):

• দিনে ১ কোটি (১০^৭) নতুন ছোট link তৈরি হয়।
• প্রতিটি link গড়ে ১০০ বার খোলা হয় — read:write = ১০০:১, এটিও ধরে নেওয়া।
• একটি record (ছোট code, আসল URL, সময়, মালিক, মেয়াদ) প্রায় ৫০০ byte; redirect-এর উত্তরও প্রায় ৫০০ byte.
• ডেটা রাখতে হবে ৫ বছর, প্রতিটির ৩টি কপি; peak factor ৩।

এবার সংখ্যাগুলো নকশার ছবিতে বসাই — প্রতিটি হিসাব একটি বাক্সের আকার বা তীরের ভার ঠিক করে:

উপসংহার: URL shortener-এর চাপ পড়ে read-এর পথে, তাই নকশার মূল প্রশ্ন cache আর দ্রুত খোঁজা; storage মাঝারি, network হালকা। সামনের load balancer অনুরোধ ভাগ করে, কিন্তু ভিড় সামলায় cache — পর্ব ৫৪-এর নকশার দিক এখানেই ঠিক হয়ে যায়।

৭ · উদাহরণ খ ও গ — ছবি শেয়ারিং আর chat অ্যাপ

এবার বড় ফাইলের সিস্টেম। একটি ছবি শেয়ারিং অ্যাপ (কাল্পনিক) — ধরা যাক:

• দিনে ২০ লাখ (২ × ১০^৬) ছবি upload হয়; মূল ছবি আর ছোট সংস্করণ মিলিয়ে গড়ে ২ MB.
• দিনে ২০ কোটি (২ × ১০^৮) বার ছবি দেখা হয়; ফোনে পাঠানো সংস্করণ গড়ে ২০০ KB.
• প্রতিটি ছবির ৩টি কপি, ছবি কখনো মোছা হয় না, peak factor ২।

উদাহরণ গ — chat অ্যাপ: ছোট বার্তা, বিশাল সংখ্যা

এবার উল্টো চরিত্রের সিস্টেম — জিনিস ছোট, সংখ্যা অগণিত। ধরা যাক একটি chat অ্যাপ (কাল্পনিক): দৈনিক সক্রিয় ব্যবহারকারী ৫ কোটি, প্রত্যেকে দিনে ৪০টি বার্তা পাঠান, একটি বার্তা metadata-সহ ২০০ byte, peak factor ৫।

এখানে চাপ write-এর দিকে: peak-এ প্রতি সেকেন্ডে এক লাখের বেশি বার্তা লিখতে হবে। আর group chat-এ একটি বার্তা থেকে অনেকগুলো delivery তৈরি হয় — একে বলে fan-out, যা বাইরে যাওয়া বার্তার সংখ্যা কয়েক গুণ বাড়ায় (পর্ব ৫৫)। বার্তা ছোট বলে bandwidth মাঝারি: গড়ে প্রায় ৩৭ Mbit/s ভেতরে আসে।

কিন্তু একটি জিনিস এতক্ষণ ধরা হয়নি — বৃদ্ধি। সফল অ্যাপে প্রতি বছর ব্যবহার বাড়ে। নিচের কোড বছরে ৪০% বৃদ্ধি (ধরে নেওয়া), তিনটি কপি আর index-metadata-র জন্য ৩০% overhead নিয়ে ৫ বছরের হিসাব করে:

// Storage growth for a chat service. All inputs are assumptions: change them and run again.
const perDay0 = 400e9;    // year 1: 2 billion messages/day x 200 bytes = 400 GB new data per day
const growth = 0.40;      // new data per day grows 40% every year
const replication = 3;    // three copies of every byte
const overhead = 1.3;     // indexes, metadata, free space: +30%
const years = 5;
const TB = 1e12, f = (x) => x.toFixed(0);
const row = (a, b, c, d, e) => a.padEnd(5) + b.padStart(9) + c.padStart(13) + d.padStart(12) + e.padStart(14);
let total = 0, flat = 0;
console.log(row("year", "new/day", "added/year", "total raw", "provisioned"));
for (let y = 1; y <= years; y++) {
  const perDay = perDay0 * (1 + growth) ** (y - 1);
  const added = perDay * 365;
  total += added;
  flat += perDay0 * 365;                  // the same years with no growth
  console.log(row(String(y), f(perDay / 1e9) + " GB", f(added / TB) + " TB", f(total / TB) + " TB",
                  f(total * replication * overhead / TB) + " TB"));
}
console.log("provisioned = total raw x" + replication + " copies x" + overhead + " overhead");
console.log("No growth: " + f(flat / TB) + " TB raw after " + years + " years, not " + f(total / TB) + " TB");

year   new/day   added/year   total raw   provisioned
1       400 GB       146 TB      146 TB        569 TB
2       560 GB       204 TB      350 TB       1367 TB
3       784 GB       286 TB      637 TB       2483 TB
4      1098 GB       401 TB     1037 TB       4045 TB
5      1537 GB       561 TB     1598 TB       6232 TB
provisioned = total raw x3 copies x1.3 overhead
No growth: 730 TB raw after 5 years, not 1598 TB

৮ · উদাহরণ ঘ — কতগুলো সার্ভার: utilization আর headroom

URL shortener-এর peak ছিল প্রায় ৩৫,০৬৯ অনুরোধ/সেকেন্ড। কতগুলো সার্ভার লাগবে? সরল উত্তর — একটি সার্ভার যত সামলায়, তা দিয়ে ভাগ। কিন্তু আগে দুটি প্রশ্ন: একটি সার্ভার আসলে কত সামলায়, আর তাকে কতটা ব্যস্ত রাখা নিরাপদ?

প্রথম প্রশ্নের উত্তর আসে মাপ থেকে: load test-এ চাপ বাড়িয়ে দেখা হয় কোন চাপ পর্যন্ত latency, বিশেষ করে p99 (পর্ব ৪), গ্রহণযোগ্য থাকে। দ্বিতীয়টির উত্তর queueing-এর গণিতে।

এর গাণিতিক রূপ সবচেয়ে সরল queueing মডেল M/M/1-এ (এলোমেলো আগমন, একটি সার্ভার): একটি অনুরোধের গড় মোট সময় T = S ÷ (১ − ρ), যেখানে S হলো একটি অনুরোধের নিজের কাজের সময় আর ρ হলো utilization, অর্থাৎ সার্ভার সময়ের কত অংশ ব্যস্ত।

৬০% থেকে ৯০%-এ গেলে গড় সময় চার গুণ, ৯৯%-এ চল্লিশ গুণ। বাস্তব সিস্টেম এই মডেলের মতো সরল নয়, কিন্তু বক্ররেখার আকার একই — ১-এর কাছে গিয়ে খাড়া ওপরে ওঠে। Little-এর সূত্র আর queueing-এর পূর্ণ যুক্তি পর্ব ৪-এ, overload সামলানো পর্ব ১৮-এ। তাই peak-এ মোটামুটি ৫০–৭০% utilization একটি প্রচলিত লক্ষ্য; বাকিটুকু headroom.

ρ      T ÷ S
0.50   2
0.60   2.5  ← লক্ষ্য
0.80   5
0.90   10
0.95   20
0.99   100  ← বিস্ফোরণ

শেষ একটি sanity check: ৩২টি সার্ভারের মোট ক্ষমতা ৬৪,০০০/s, অথচ গড় চাপ মাত্র ১১,৬৯০/s — দিনের গড়ে সার্ভারগুলো মাত্র প্রায় ১৮% ব্যস্ত থাকে। Peak-এর জন্য সারাদিন যন্ত্র ভাড়া রাখা দামি; এখান থেকেই চাপ অনুযায়ী সার্ভার বাড়ানো-কমানোর ধারণা, autoscaling (পর্ব ১৩)।

৯ · Sanity check আর সাধারণ ভুল

হিসাব শেষ — কিন্তু ঠিক তো? অভিজ্ঞ প্রকৌশলীরা উত্তর হাতে পেয়েই কয়েকটি প্রশ্ন করেন:

• একক মিলছে কি? প্রতিটি সূত্রের দুই পাশের একক কাটাকাটি করে দেখুন।
• প্রতি ব্যবহারকারীর হিসাবে যুক্তিসংগত কি? ছবির অ্যাপে ১ কোটি দৈনিক ব্যবহারকারী ধরলে দিনে ২০ লাখ upload মানে প্রতি পাঁচ জনে একজন দিনে একটি ছবি দেন — বিশ্বাসযোগ্য। প্রত্যেকে দিনে ৫০০টি এলে কোথাও ভুল আছে।
• দুই পথে মিলছে কি? ওপর থেকে (ব্যবহারকারী × ব্যবহার) আর নিচ থেকে (একটি সার্ভার বা disk কত পারে) — দুই হিসাব একই মাত্রায় না এলে কোনো input ভুল।
• পরিচিত সীমার সাথে তুলনা। একটি hard disk-এ সেকেন্ডে শখানেক random read, একটি লিংকে কয়েক Gbit/s — উত্তর এমন সীমা ছাড়ালে ভাগ করা বা cache লাগবে।

এর মধ্যে এককের ভুলগুলো যন্ত্র দিয়েই ধরা যায়। নিচের ছোট “একক পরীক্ষক” প্রতিটি দাবির দুই পাশ bit আর সেকেন্ডে বদলে তুলনা করে, আর না মিললে অনুপাত দেখে সম্ভাব্য কারণ বলে:

// Units sanity checker: each claim says "left = right". Both sides are turned into base
// units (bits, requests, seconds); a mismatch is flagged with its most likely cause.
const SIZE = { bit: 1, Kbit: 1e3, Mbit: 1e6, Gbit: 1e9, B: 8, KB: 8e3, MB: 8e6, GB: 8e9, TB: 8e12, req: 1 };
const TIME = { s: 1, h: 3600, day: 86400 };
function base(v, unit) { const [s, t] = unit.split("/"); return v * SIZE[s] / (t ? TIME[t] : 1); }
const causes = [[8, "bits vs bytes"], [24, "divided by 3,600 not 86,400"],
                [86400, "per day vs per second"], [1000, "lost a x1000 prefix"]];
function guess(r) {
  const big = r > 1 ? r : 1 / r;
  for (const [f, why] of causes) if (Math.abs(big / f - 1) < 0.05) return why + " (x" + f + ")";
  return "off by x" + big.toFixed(1);
}
const claims = [
  ["photo egress", 463, "MB/s", 3.7, "Gbit/s"],
  ["photo egress", 463, "MB/s", 463, "Mbit/s"],
  ["photo ingest", 4, "TB/day", 46.3, "MB/s"],
  ["URL writes", 10e6, "req/day", 2778, "req/s"],
  ["chat storage", 400, "GB/day", 400, "GB/s"],
  ["5-year data", 27.4, "TB", 27400, "MB"],
  ["home link", 100, "Mbit/s", 12.5, "MB/s"],
];
for (const [what, a, ua, b, ub] of claims) {
  const r = base(a, ua) / base(b, ub);
  const ok = Math.abs(r - 1) < 0.02;
  console.log(what.padEnd(13) + (a + " " + ua + " = " + b + " " + ub).padEnd(32) +
              (ok ? "OK" : "WRONG: " + guess(r)));
}

photo egress 463 MB/s = 3.7 Gbit/s           OK
photo egress 463 MB/s = 463 Mbit/s           WRONG: bits vs bytes (x8)
photo ingest 4 TB/day = 46.3 MB/s            OK
URL writes   10000000 req/day = 2778 req/s   WRONG: divided by 3,600 not 86,400 (x24)
chat storage 400 GB/day = 400 GB/s           WRONG: per day vs per second (x86400)
5-year data  27.4 TB = 27400 MB              WRONG: lost a x1000 prefix (x1000)
home link    100 Mbit/s = 12.5 MB/s          OK

১০ · AI-এর যুগে estimation

AI-কে একটি chat অ্যাপের estimation করতে বললে কয়েক সেকেন্ডে সুন্দর সাজানো উত্তর আসে — টেবিল, সংখ্যা, সব। সমস্যা হলো, সুন্দর দেখানো আর ঠিক হওয়া এক জিনিস নয়। AI-এর লেখা estimation-এ বারবার যে ভুলগুলো দেখা যায়:

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

• প্রতিটি গুণ-ভাগ নিজে বা calculator-এ আবার করেছি — বিশেষ করে ৮৬,৪০০, ×৮ আর ×১,০০০
• প্রতিটি ধরে নেওয়া মান চিহ্নিত করেছি, আর জানি কোনটি বদলালে উত্তর সবচেয়ে বেশি বদলায়
• Replication, index-overhead আর peak হিসাবে আছে কি না দেখেছি
• Product limit বা দাম অফিসিয়াল documentation-এ মিলিয়েছি; সার্ভারের ক্ষমতা নিজের load test থেকে নিয়েছি
• প্রতিটি উপাদানের (cache, queue, shard) পক্ষে একটি সংখ্যা দেখাতে পারি, আর সেটি নষ্ট হলে কী হবে ভেবেছি