Capacity Estimation (Napkin Math)
- ●Capacity estimation মানে DAU থেকে QPS, storage, bandwidth—মোটামুটি হিসাব করা, নিখুঁত নয়।
- ●Read:write ratio, powers of 2, আর latency numbers জানা থাকলে দ্রুত napkin math করা যায়।
- ●লক্ষ্য সঠিক উত্তর নয়—সিস্টেমের scale ও bottleneck বোঝা; তাই round number ব্যবহার করো।
সমস্যাটা কী?
Interview-তে interviewer বললেন—"Twitter-এর মতো একটা সিস্টেম ডিজাইন করো।" তুমি সুন্দর diagram আঁকলে, কিন্তু তিনি জিজ্ঞেস করলেন—"তোমার এই সিস্টেমে দিনে কত request আসবে? কত storage লাগবে? একটা সার্ভার কি যথেষ্ট, নাকি ১০০টা?" এখন যদি তুমি বলো "জানি না"—পুরো ডিজাইন বাতাসে ঝুলে থাকে।
এই প্রশ্নগুলোর মোটামুটি উত্তর দ্রুত বের করাকেই বলে capacity estimation বা Napkin Math। লক্ষ্য একদম নিখুঁত সংখ্যা নয়—লক্ষ্য হলো বোঝা সিস্টেমটা কত বড়, কোথায় চাপ পড়বে, কয়টা সার্ভার/কত storage লাগবে। এই হিসাবই ঠিক করে দেয় তোমার design realistic কিনা।
মূল ধারণা
Capacity estimation হলো কিছু মৌলিক সংখ্যা (যেমন daily active users) থেকে শুরু করে সিস্টেমের QPS, storage, ও bandwidth-এর approximate চাহিদা হিসাব করার প্রক্রিয়া—যেখানে নিখুঁততার চেয়ে দ্রুততা ও order-of-magnitude বোঝা বেশি গুরুত্বপূর্ণ।
মূলমন্ত্র: round number ব্যবহার করো। 86,400 সেকেন্ড/দিনকে ~100,000 ধরে নাও, 1 million-কে 10^6 ভাবো। তোমার হিসাব ২ গুণ এদিক-ওদিক হলেও সমস্যা নেই—তুমি জানতে চাও 10 না 10,000, ঠিক 1,234 কিনা সেটা নয়।
কীভাবে কাজ করে
ধাপ ১: DAU → QPS
DAU (daily active users) = 100,000,000 (100M)
গড় request/user/দিন = 10
মোট request/দিন = 100M × 10 = 1,000,000,000 (1B)
একদিনে সেকেন্ড ≈ 86,400 (round: ~100,000)
গড় QPS = 1B / 86,400 ≈ 11,500 QPS
Peak QPS (সাধারণত 2x–3x গড়) ≈ 23,000 – 35,000 QPS
সবসময় peak-এর জন্য ডিজাইন করো, গড়ের জন্য নয়—কারণ peak সামলাতে না পারলে peak সময়ে সিস্টেম ভেঙে পড়ে।
ধাপ ২: Read : Write Ratio
বেশিরভাগ সিস্টেম read-heavy। ধরো ratio 100:1 (যেমন social feed)। উপরের ~11,500 QPS-কে ভাগ করলে:
| ধরন | অনুপাত | QPS (গড়) |
|---|---|---|
| Read | 100 | ~11,400 |
| Write | 1 | ~115 |
এই ratio গুরুত্বপূর্ণ—read-heavy হলে cache ও read replica-তে জোর দাও; write-heavy হলে database write path ও sharding নিয়ে ভাবো।
ধাপ ৩: Storage / Year
দৈনিক write = 115 write/sec × 86,400 sec ≈ 10,000,000 (10M) নতুন রেকর্ড/দিন
প্রতি রেকর্ডের আকার = 1 KB
দৈনিক storage = 10M × 1 KB = 10 GB/দিন
বাৎসরিক storage = 10 GB × 365 ≈ 3,650 GB ≈ 3.6 TB/বছর
5 বছরের জন্য ≈ 18 TB (replication বাদে; 3x replica ধরলে ~54 TB)
ধাপ ৪: Bandwidth
Read response আকার = 1 KB (ধরো)
Read egress = 11,400 read/sec × 1 KB ≈ 11,400 KB/s ≈ 11 MB/s
≈ 88 Mbps (1 byte = 8 bit)
Powers of 2 — দ্রুত byte হিসাব
| Power | মান | প্রায় | একক |
|---|---|---|---|
| 2^10 | 1,024 | ~1 thousand | KB |
| 2^20 | ~1,048,576 | ~1 million | MB |
| 2^30 | ~1.07 billion | ~1 billion | GB |
| 2^40 | ~1.1 trillion | ~1 trillion | TB |
এগুলো মুখস্থ থাকলে "1 KB রেকর্ড × 1 billion" মানে সাথে সাথেই ~1 TB বলতে পারবে।
ভাবো তুমি ঈদে বাড়িতে বিরিয়ানির আয়োজন করছ। তুমি ঠিক ক্যালকুলেটর নিয়ে বসো না—মনে মনে হিসাব করো: "১০০ জন অতিথি, জনপ্রতি গড়ে ১.৫ প্লেট, মানে ১৫০ প্লেট। এক কেজি চালে ~৫ প্লেট, তাই ~৩০ কেজি চাল।" এটাই napkin math—round number দিয়ে দ্রুত আনুমানিক হিসাব, যাতে বুঝতে পারো ৫ কেজি না ৩০ কেজি চাল লাগবে। ১ কেজি এদিক-ওদিক হলে রান্নায় সমস্যা নেই; কিন্তু ৫ vs ৫০ গুলিয়ে ফেললে হয় অতিথি অভুক্ত, নয় বিপুল অপচয়।
কৌশল: Latency Numbers Every Engineer Should Know
কোন কাজ কত ধীর তার আনুমানিক ধারণা থাকলে দ্রুত বোঝা যায় bottleneck কোথায়।
| অপারেশন | আনুমানিক সময় |
|---|---|
| L1 cache reference | ~1 ns |
| Main memory (RAM) reference | ~100 ns |
| SSD random read | ~16 µs (~16,000 ns) |
| একই datacenter-এ round trip | ~500 µs |
| Disk (HDD) seek | ~10 ms |
| একই অঞ্চলে network round trip | ~1 ms |
| মহাদেশ পার করে (যেমন US ↔ Europe) round trip | ~150 ms |
মূল শিক্ষা: memory disk-এর চেয়ে হাজার গুণ দ্রুত, আর network-এর দূরত্ব latency-তে বিশাল পার্থক্য আনে। এজন্যই cache (memory) ব্যবহার করি এবং user-এর কাছে data (CDN) রাখি।
কখন ব্যবহার করবে / করবে না
প্রতিটি system design-এর শুরুতেই capacity estimation করো—এটা ঠিক করে দেয় তোমার সিস্টেম single server-এ চলবে নাকি distributed হতে হবে, cache লাগবে কিনা, sharding দরকার কিনা। কিন্তু এর পেছনে ঘণ্টার পর ঘণ্টা ব্যয় কোরো না—২-৩ মিনিটে round number দিয়ে সেরে ফেলো।
Capacity estimation-কে নিখুঁত গণিত ভেবে ভুল কোরো না। তুমি যদি 86,400-এর বদলে 100,000 ব্যবহার করো, ফল ~15% এদিক-ওদিক হবে—তাতে কিছু যায় আসে না। বরং বড় ভুল হলো peak-এর বদলে গড় QPS দিয়ে capacity নেওয়া, কিংবা replication ও overhead বাদ দেওয়া (আসল storage প্রায়ই হিসাবের 3x, কারণ 3 replica)। আনুমানিক হিসাবেও এই multiplier-গুলো ধরতে ভুলো না, নইলে সিস্টেম under-provisioned হবে।
বাস্তব উদাহরণ
- Google-এর engineering culture-এ এই "back-of-the-envelope calculation" দক্ষতা বিখ্যাত; Jeff Dean-এর প্রচারিত "Latency Numbers Every Programmer Should Know" তালিকাটি প্রায় প্রতিটি system design ইন্টারভিউ প্রস্তুতিতে পড়ানো হয়।
- Twitter-এর fan-out ডিজাইন করার সময় ইঞ্জিনিয়াররা ঠিক এভাবে হিসাব করেন—কত tweet/sec, প্রতিটি tweet কত follower-এর timeline-এ যাবে, ফলে কত write amplification—এই napkin math থেকেই "fan-out on write vs on read" সিদ্ধান্ত আসে।
- যেকোনো বড় কোম্পানির capacity planning team এই একই নীতিতে কাজ করে—DAU growth থেকে আগামী বছরের server ও storage budget অনুমান করে।
Interview-তে capacity estimation চাইলে জোরে জোরে assumption বলো—"ধরছি 100M DAU, প্রতি user দিনে 10 request, read:write 100:1।" তারপর round number-এ ধাপে ধাপে এগোও আর peak-এর জন্য 2x–3x গুণ করতে ভুলো না। Interviewer সঠিক সংখ্যা চায় না—চায় দেখতে তুমি কাঠামোবদ্ধভাবে (DAU → QPS → storage → bandwidth) ভাবতে পারো কিনা।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. 100 million DAU প্রতি একদিনে গড়ে 10টি request করলে গড় QPS মোটামুটি কত?
2. Capacity estimation-এ powers of 2 জানা কেন দরকার?
3. Capacity estimation-এর আসল লক্ষ্য কী?