Module 1 · Day 3

Back-of-the-Envelope Estimation

খামের পেছনের হিসাব — box আঁকার আগে দুই লাইনের ভাগ-গুণে system-এর আকার বোঝা: data-size-এর মই, QPS-এর recipe, storage সময়ের সাথে কীভাবে বাড়ে, আর cache size করার 80/20 rule।

~120 min read5 learning objectives

What you'll learn

•back-of-the-envelope estimation কী, আর design আঁকার আগে কেন এটা system-এর আকার ঠিক করে দেয় — বলতে পারা।
•data-size-এর মই (KB → MB → GB → TB → PB) সাবলীলভাবে পড়া; একটা tweet/photo/video মোটামুটি কত — জানা।
•aggressive rounding: 86,400 ≈ 10⁵ ধরে মাথায় এক লাইনে QPS কষা — exact নয়, order of magnitude।
•QPS recipe: DAU × actions ÷ 86,400 → average; × peak factor → peak; read/write ratio দিয়ে আলাদা করা।
•storage = write QPS × payload × time × replication, আর cache size করতে 80/20 rule (hot working set)।

Before this

•Day 1 — system design কী, latency vs throughput, ৫-ধাপি framework (estimation ছিল ২ নম্বর ধাপ)।
•Day 2 — requirements ও scope; DAU, read/write ratio-র ধারণা।
•স্কুলের ভাগ-গুণ আর powers of ten (10³, 10⁶) চেনা — এর বেশি কোনো math লাগবে না।

Why Estimate First

design আঁকার আগে system-এর আকার জানা।

"একটা Twitter design করো" শুনে box আঁকা শুরু করার আগে একটা প্রশ্ন: system-টা আসলে কত বড়? এক machine-এ হবে, নাকি অনেক machine + cache + sharding লাগবে? উত্তরটা দেয় back-of-the-envelope estimation — দুই লাইনের ভাগ-গুণ।

ভয়ের কিছু নেই — এ কোনো কঠিন math নয়। আসল কৌশল হলো round aggressively: 86,400-কে 10⁵ ধরো, তাহলে মাথায় এক লাইনেই QPS বেরিয়ে আসে। estimation নিখুঁততার খেলা নয়, order of magnitude-এর খেলা।

আজ পাঁচটা জিনিস হাতে-কলমে: data-size-এর মই, rounding-এর অভ্যাস, QPS-এর recipe, storage সময়ের সাথে কীভাবে বাড়ে, আর cache size করার 80/20 rule।

estimationbefore you draw a single box

design আঁকার আগে দুই লাইনের ভাগ-গুণে system-এর আকার বের করা — এক machine-এ হবে, নাকি অনেক machine + cache + sharding লাগবে। এই order-of-magnitude-টাই পরের সব সিদ্ধান্ত ঠিক করে। under-estimate করলে outage, over-estimate করলে সারা বছরের সার্ভার-বিল গচ্চা।

Why it matters

৫০০ জনের বিয়ের রান্নায় বাবুর্চি আগে চাল-মাংস ওজন করে নেয় — হিসাব না করলে হয় কম পড়বে (অতিথি না খেয়ে ফিরবে), নয় দ্বিগুণ কিনে টাকা নষ্ট।

Size Language and Rounding

powers of two, আর aggressive rounding-এর অভ্যাস।

Interactive · data-size ladder

size-এর ভাষা শেখো

storage estimate করতে হলে আগে জানতে হবে — একটা tweet কত বড়, একটা photo কত। মই-এর প্রতি ধাপে প্রায় ×১০০০। একটা ধাপে ট্যাপ করো।

1 MB

~১০০০ KB

~একটা photo, বা একটা গান (mp3)

মনে রাখো: প্রতি ধাপ ~×১০০০। একটা post ~১ KB, ১০ লক্ষ post ~১ GB — এই জোড়া দিয়েই storage আন্দাজ করবে।

powers of twoKB · MB · GB · TB · PB

data-size-এর মই: প্রতি ধাপে প্রায় ×১০০০ — KB (~একটা tweet), MB (~একটা photo), GB (~১০০০ photo / সিনেমার অংশ), TB (~বড় database), PB (বিশাল)। এই sizes মাথায় থাকলে storage estimate চটজলদি হয়। (binary-তে ১০২৪, কিন্তু estimation-এ ~১০০০ ধরো।)

Why it matters

বাজারে গ্রাম-কিলো-মণ না জানলে যেমন হিসাব হয় না, byte → KB → MB → GB না জানলে storage estimate হয় না। আগে size-এর ভাষা শেখো।

Interactive · rounding dojo

1/4 · score 0

estimation-এর আসল কৌশল — কষার আগে round করা। নিচের সংখ্যাটাকে estimation-friendly রূপে নাও।

86,400

এক দিনে কত সেকেন্ড — QPS কষতে এটাকে কীসে round করবে?

মনে রাখো: estimation order of magnitude-এর খেলা। বলো — these are order-of-magnitude numbers.

order of magnituderound aggressively

মাথায় নিখুঁত গুণ (86,400 × 5,000,000) কষতে যেও না — আগে round করো: 86,400 ≈ 10⁵, এক বছরের সেকেন্ড 31,536,000 ≈ 3×10⁷। তারপর powers of ten মেলাও। estimation নিখুঁততার নয়, order of magnitude-এর খেলা।

Why it matters

"১৫০ kg চাল নাকি ১৪৭.৩ kg" — বিয়ের বাজারে কেউ জিজ্ঞেস করে না। কাছাকাছিটাই কাজ চালায়, আর মাথায় এক লাইনে কষা যায়।

The QPS Recipe

DAU → average → peak → read/write split।

Interactive · QPS recipe, step by step

এক লাইনে QPS কষো

Day 1-এ slider টেনেছিলে — এবার method-টা শেখো। Next চাপো, প্রতিটা লাইন round করে কীভাবে আসে দেখো। calculator লাগবে না।

DAU = 5,000,000 = 5 × 10⁶

ধরো ৫ মিলিয়ন daily active user। powers of ten-এ লেখো।

× 10 actions/user = 5 × 10⁷ / দিন

÷ 86,400 (≈ 10⁵) → avg ≈ 500 QPS

× 3 (peak factor) → peak ≈ 1,500 QPS

read:write = 100:1 → ~1,485 read, ~15 write /s

মনে রাখো এই recipe: DAU × actions ÷ 86,400 → average; × peak factor → peak; read/write দিয়ে আলাদা করো।

QPSqueries per second

average QPS = DAU × actions/user ÷ 86,400। এটাই estimation-এর প্রথম সংখ্যা। মনে রাখার কৌশল: 86,400-কে 10⁵ ধরো, বাকিটা powers of ten-এ ভাঙো — calculator লাগবে না।

Why it matters

৫M DAU, জনপ্রতি ১০ action ⇒ 5×10⁷ ÷ 10⁵ = ~500 QPS — এক লাইনে। এই একটা সংখ্যা দিয়েই design-এর আকার আঁচ করা যায়।

peak factorread-to-write ratio

দুটো সংখ্যা পুরো design ঘোরায়। peak QPS = average × peak factor (সাধারণত 2–5×, sale/ঈদে ১০–২০×) — সবসময় peak ধরে provision করো, average ধরে নয়। আর read/write ratio: read-heavy → cache + read replica + CDN; write-heavy → queue/partition।

Why it matters

Daraz ১১.১১-তে স্বাভাবিকের ১০×+ traffic, আর ভীষণ read-heavy (দেখে অনেক, কেনে কম)। peak + read-heavy — এই দুটো জানলেই বোঝা যায় cache আর extra server লাগবে।

Storage Grows Over Time

payload × time × replication।

Interactive · storage over time

per-second ছোট, per-year বিশাল

storage = write QPS × payload × time × replication। time horizon-টা টানো — দেখো ছোট সংখ্যাটা কীভাবে sharding-এ বাধ্য করে।

write QPS500

payload2 KB

replication ×3×

1 বছর-এ মোট storage

94.6 TB

⚠ এক machine-এ ধরবে না — sharding লাগবে

মনে রাখো: time horizon আর replication factor (×৩) — এই দুটোই beginners ভুলে যায়, আর এ দুটোই সংখ্যাটা বিশাল করে।

replication factorstorage over time

storage = write QPS × payload size × সময় × replication factor (সাধারণত ৩ কপি durability-র জন্য)। per-second সংখ্যাটা ছোট দেখায়, কিন্তু ১ বা ৫ বছরে গুণ করলে এটাই এক disk ছাড়িয়ে storage cluster বা sharding-এ ঠেলে দেয়।

Why it matters

দিনে ১ টাকা জমানো তুচ্ছ, কিন্তু ৫ বছরে ~১৮০০ টাকা। storage-ও তেমন — সময় আর ৩ কপি দিয়ে গুণ করলেই আসল আকার বেরোয়।

Cache Size — the 80/20 Rule

hot working set, আর কখন estimate skip করবে।

Interactive · 80/20 cache sizer

পুরোটা cache কোরো না

সব data RAM-এ রাখা টাকার অপচয়। 80/20 rule: অল্প hot data বেশির ভাগ read সামলায়। কতটা cache করবে — slider টানো।

cache করছি hot20% keys

এই hot set যত % read সামলায়80%

cache RAM লাগবে

200 GB

20% × 1 TB

read hit rate

80%

বাকিটা DB-তে যাবে

লক্ষ্য করো: ~২০%-এ পৌঁছালেই ~৮০% read ধরা পড়ে; এরপর আরও cache করলে লাভ কমতে থাকে। বলো — I'll cache the hot 20%.

the 80/20 ruleworking set

পুরো data cache করার দরকার নেই: ২০% hot data সাধারণত ৮০% read সামলায় (Pareto)। শুধু সেই hot working set-টা RAM-এ cache করলে অল্প খরচে বড় লাভ — পুরোটা cache করা টাকা ও RAM-এর অপচয়।

Why it matters

দোকানের সামনের তাকে শুধু best-selling জিনিস রাখা হয়; সব stock সামনে রাখার দরকার নেই। যেগুলো বেশি বিকোয় (hot) সেগুলোই হাতের কাছে।

when to skipestimation as a tool

সব সময় estimate করতেই হবে না। সংখ্যাটা যদি কোনো সিদ্ধান্ত না বদলায় (এক node-এ হবে, নাকি shard লাগবে — উত্তর যাই হোক একই), তাহলে estimation শুধু সময় নষ্ট। যেখানে সংখ্যা design বদলায়, ঠিক সেখানেই কষো।

Why it matters

১০ জনের রান্নায় কেউ গ্রাম ধরে ওজন করে না — চোখের আন্দাজই যথেষ্ট। হিসাব তখনই দরকার, যখন সংখ্যাটা সিদ্ধান্ত পাল্টে দেয়।

Check Your Understanding

ভুল করলেও সমস্যা নেই — প্রতিটার ব্যাখ্যা আছে।

Misconception check

Estimation মানে নিখুঁত, সঠিক সংখ্যা বের করা।

Misconception check

মাথায় বড় গুণ (86,400 × 5,000,000) কষতে হবে।

Misconception check

Average QPS দিয়ে provision করলেই হবে।

Misconception check

Storage মানে শুধু payload × QPS।

Misconception check

ভালো performance-এর জন্য পুরো dataset cache করতে হবে।

Misconception check

Read আর write QPS এক, আলাদা করার দরকার নেই।

Misconception check

Interview-এ সবসময় estimation করতেই হবে।

Quick check