Back-of-the-envelope estimation

০. TaskFlow এখন কোথায়

গত lesson এ আমরা 5-step framework শিখেছি, আর তুমি লক্ষ্য করেছ — Step 2 (Estimation) আর Step 1 (Requirements) এর মধ্যে লাইনটা টানতে একটু সমস্যা হয়েছিল। আজকে ঠিক সেই Step 2 নিয়ে গভীরে যাব।

কল্পনা করো — তুমি TaskFlow এর "Search" feature এর জন্য architecture ঠিক করতে বসেছ (গত lesson এর exercise)। তোমার হাতে দুটো option:

1. সরাসরি PostgreSQL এ LIKE query চালানো
2. একটা আলাদা Elasticsearch cluster বসানো

কোনটা ঠিক? উত্তরটা নির্ভর করে — কত task আছে, কত ঘন ঘন search হয়। যদি TaskFlow এ মোট ১০,০০০ task থাকে আর দিনে ৫০ বার search হয় — option ১ ঠিকভাবে চলবে, Elasticsearch বসানো ওভারকিল। কিন্তু যদি ১ কোটি task থাকে, সেকেন্ডে ৫০০ বার search হয় — option ১ ভেঙে পড়বে।

এই সংখ্যাটাই তোমাকে সিদ্ধান্ত নিতে সাহায্য করে — অনুমান দিয়ে না, হিসাব দিয়ে। আজকে আমরা শিখব কীভাবে এই হিসাবটা দ্রুত, মোটামুটি নির্ভুলভাবে, মাথায় মাথায় করতে হয়।

১. Theory

১.১ কেন "মোটামুটি" যথেষ্ট — নিখুঁত হিসাবের দরকার নেই

Back-of-the-envelope মানেই হলো — একটা খামের পেছনে (বা napkin এ) দ্রুত লেখা একটা rough হিসাব, calculator ছাড়া, ৯৫% নিখুঁত হওয়ার দরকার নেই। উদ্দেশ্য হলো — সঠিক মাত্রা (order of magnitude) বোঝা। তুমি জানতে চাও system টা "হাজার" scale এ, নাকি "লাখ" scale এ, নাকি "কোটি" scale এ — কারণ সেটার ওপর নির্ভর করেই architecture এর ধরন সম্পূর্ণ বদলে যায়।

উদাহরণ — তুমি যদি হিসাব করে পাও storage লাগবে "৫০০ GB এর আশেপাশে", সেটা ৪৫০ হোক বা ৫৫০ হোক — কোনো পার্থক্য করে না architecture এর জন্য। কিন্তু "৫০০ GB" আর "৫০০ TB" এর পার্থক্য architecture সম্পূর্ণ বদলে দেয়। তাই এই ধাপে আমরা কখনো calculator খুঁজব না — round number নিয়ে কাজ করব (যেমন, ১০০০ ইউজার না বলে "প্রায় ১ হাজার", ৩৬৫ দিন না বলে "প্রায় ৩৬০")।

১.২ মুখস্থ রাখার মতো কিছু Base Number

Power of 2 আর তাদের approximate value (storage এর জন্য):

মনে রাখার সহজ trick: প্রতি ১০ power বাড়লে, মান প্রায় ১০২৪ গুণ বাড়ে (যেটাকে rough হিসাবে ১০০০ গুণ ধরে নিলেই চলে)।

Time-related সংখ্যা যেগুলো বারবার লাগবে:

"১ দিন = ~১,০০,০০০ সেকেন্ড" — এই একটা approximation তোমাকে অনেক হিসাব সহজ করে দেবে। (আসল সংখ্যা ৮৬,৪০০ — কিন্তু ১,০০,০০০ ধরে নিলে মাথায় মাথায় ভাগ করা অনেক সহজ, আর error মাত্র ~১৫%, যেটা এই ধরনের rough estimation এ acceptable।)

Latency Numbers (কোন operation কত সময় নেয়, মোটামুটি):

এই টেবিলটা তোমার জন্য বিশেষভাবে গুরুত্বপূর্ণ, কারণ পরের modules (Caching, Database) এ এই numbers বারবার প্রসঙ্গ আসবে।

এই টেবিল থেকে সবচেয়ে গুরুত্বপূর্ণ takeaway: Memory read আর Disk read এর মধ্যে পার্থক্য প্রায় হাজার গুণ। এটাই মূল কারণ কেন caching (Module 4) এত গুরুত্বপূর্ণ একটা concept — একই data বারবার disk থেকে না পড়ে memory থেকে পড়লে, হাজার গুণ দ্রুত হয়।

১.৩ Estimation এর সাধারণ Process

একটা সংখ্যা বের করতে গেলে, সাধারণত এই ধাপগুলো অনুসরণ করা হয়:

১. মোট ইউজার (Total Users)
        │
        ▼
২. Daily Active User (DAU) — সবাই তো রোজ ব্যবহার করে না
        │
        ▼
৩. প্রতি ইউজার কত বার নির্দিষ্ট action করে (per day)
        │
        ▼
৪. মোট action/day  →  সেকেন্ডে কত request (QPS)
        │
        ▼
৫. প্রতি action এ কত data — মোট storage/bandwidth

চলো TaskFlow দিয়ে একটা concrete উদাহরণ দেখি।

উদাহরণ: TaskFlow এর Notification feature এর জন্য QPS বের করা

ধরো, client বলেছে — "১০ লাখ (১ মিলিয়ন) registered user টার্গেট।"

ধাপ ১ — DAU বের করা: সব registered user রোজ app খোলে না। Industry rough assumption — DAU সাধারণত total user এর ১০-২০% হয় (এটা product-ভেদে অনেক আলাদা হতে পারে, কিন্তু interview এ এই assumption বলে দিলেই যথেষ্ট)। ধরি ২০%।

→ DAU = ১০ লাখ × ২০% = ২ লাখ

ধাপ ২ — প্রতি ইউজার কতবার action করে: ধরি, একজন active ইউজার গড়ে দিনে ৫টা task assign করে (মানে ৫টা notification generate করে)।

→ মোট notification/day = ২ লাখ × ৫ = ১০ লাখ notification/day

ধাপ ৩ — এটাকে QPS এ রূপান্তর: এখানেই সেই "১ দিন ≈ ১,০০,০০০ সেকেন্ড" approximation কাজে লাগে:

→ QPS = ১০ লাখ ÷ ১,০০,০০০ = ~১০ notification/সেকেন্ড (average)

ধাপ ৪ — Peak QPS: এটা average। কিন্তু traffic সারাদিন সমান থাকে না — office hour এ বেশি, রাতে কম। একটা common rule of thumb: Peak QPS ≈ Average QPS এর ২-৩ গুণ।

→ Peak QPS = ~১০ × ৩ = ~৩০ notification/সেকেন্ড

এই "~৩০ notification/সেকেন্ড" সংখ্যাটাই এখন তোমাকে বলে দেয় — এটা কি এতটাই ছোট যে একটা single Express server handle করতে পারবে (হ্যাঁ, পারবে — এটা খুবই ছোট সংখ্যা), নাকি এর জন্য আলাদা queue/scaling দরকার (এই সংখ্যায় না, কিন্তু যদি এটা ৩০,০০০ হতো, তখন দরকার হতো)।

Storage হিসাবের উদাহরণ:

ধরো প্রতিটা notification record এ থাকে — id, message text, timestamp, user_id, read/unread flag। মোটামুটি ধরা যায় প্রতিটা record ~২০০ bytes (এই সংখ্যাটাও rough guess, নিখুঁত হওয়ার দরকার নেই)।

→ দৈনিক storage = ১০ লাখ notification × ২০০ bytes = ২০ কোটি bytes = ~২০০ MB/day

→ বছরে storage = ২০০ MB × ৩৬৫ ≈ ~৭৩ GB/year

এই সংখ্যাটা দেখে তুমি বুঝতে পারো — এটা এমন কোনো বিশাল storage সমস্যা না যে আজকেই sharding নিয়ে ভাবতে হবে (Module 5.8 তে আমরা দেখব কখন sharding সত্যিই দরকার হয়)। কিন্তু যদি হিসাব করে পেতে "৭৩ PB/year", তখন Day 1 থেকেই storage strategy আলাদাভাবে ভাবতে হতো।

Trade-off/Insight Table — Estimation না করলে কী ভুল হয়

২. Interview Angle

Estimation ধাপ interview এ প্রায়ই সবচেয়ে বেশি ভয়ের কারণ হয়, কারণ candidate রা ভাবে "নিখুঁত সংখ্যা বলতে হবে, নাহলে ভুল হয়ে যাবে"। কিন্তু বাস্তবে interviewer নিখুঁত সংখ্যা দেখে না — সে দেখে:

1. তুমি কি reasonable assumption নিতে পারছ (আর সেটা জোরে বলছ)?
2. তুমি কি সংখ্যাটা দিয়ে পরের সিদ্ধান্তে ব্যবহার করতে পারছ (শুধু হিসাব করেই থেমে না গিয়ে)?
3. তুমি কি দ্রুত, confidently কাজ করছ, নাকি প্রতিটা ধাপে আটকে যাচ্ছ?

একটা common pattern যেটা confident দেখায়: প্রতিটা assumption নেওয়ার সময় জোরে বলে দাও — "আমি ধরে নিচ্ছি DAU টোটাল ইউজারের ২০%, এটা একটা industry-common ballpark, তোমাদের actual product এ ভিন্ন হতে পারে।" এতে interviewer বোঝে তুমি জানো এটা একটা assumption, fact না — এবং প্রয়োজনে তারা তোমাকে correct করতে পারবে ("আসলে আমাদের DAU ৫০%")।

আরেকটা জিনিস — estimation থেকে বের হওয়া সংখ্যাটা অবশ্যই পরের ধাপে ব্যবহার করতে হবে। শুধু "QPS = ৩০" বলে থেমে গেলে চলবে না — বলতে হবে "যেহেতু QPS মাত্র ৩০, তাই single server-ই যথেষ্ট, load balancer এখনই লাগবে না" — এটাই estimation কে actionable করে তোলে, শুধু একটা exercise না রেখে।

৩. Key Takeaway

• Back-of-the-envelope estimation এর লক্ষ্য নিখুঁততা না, সঠিক মাত্রা (order of magnitude) বোঝা
• Round number ব্যবহার করো — ১ দিন ≈ ১,০০,০০০ সেকেন্ড, এটা মাথায় মাথায় হিসাব সহজ করে
• Memory vs Disk read এর মধ্যে পার্থক্য প্রায় ১০০০ গুণ — এটাই caching এর গুরুত্বের মূল কারণ
• সাধারণ estimation flow: Total Users → DAU → per-user action → total action/day → QPS (average) → Peak QPS (২-৩ গুণ average)
• প্রতিটা assumption জোরে বলে দাও — এটা interview তে "guess" কে "reasoned estimate" এ রূপান্তর করে
• Estimation থেকে বের হওয়া সংখ্যা অবশ্যই architecture decision এ ব্যবহার করতে হবে — শুধু হিসাব করে থেমে গেলে চলবে না

৪. নতুন Term (Glossary)

৫. Reflection Questions

আগে নিজে ভেবে উত্তর দাও, তারপর নিচের Answer Key দেখো।

1. যদি Memory read নেয় ~১০০ nanosecond, আর SSD read নেয় ~০.১ millisecond — তাহলে SSD, memory এর চেয়ে কতগুণ ধীর? (হিসাব করে দেখাও)
2. TaskFlow এর file attachment feature এ (Lesson 1.1 এর exercise থেকে মনে আছে?) — যদি DAU হয় ৫০,০০০, আর প্রতি active user দিনে গড়ে ২টা file upload করে, প্রতিটা ফাইল গড়ে ৫ MB — তাহলে দৈনিক storage বৃদ্ধি কত হবে (মোটামুটি, GB এ)?

৬. Practical Exercise

Tier 3 — Design Exercise

এবার তোমার পালা। নিচের scenario এর জন্য পুরো estimation chain টা করো — প্রতিটা ধাপ দেখিয়ে (assumption সহ)।

Scenario: TaskFlow এ একটা নতুন feature আসছে — "Activity Log": প্রতিবার কোনো task তৈরি, update, বা delete হলে, একটা log entry তৈরি হবে (কে করল, কখন করল, কী করল)।

ধরে নাও:

• Total registered user: ৫ লাখ
• DAU assumption তুমি নিজে ঠিক করো (আর কেন সেটা বলো)
• প্রতি active user গড়ে দিনে কতগুলো task action (create/update/delete মিলিয়ে) করে, সেটাও তুমি একটা reasonable সংখ্যা ধরে নাও

হিসাব করো:

1. দৈনিক মোট log entry কত হবে?
2. Average QPS কত (log write এর জন্য)?
3. Peak QPS কত (২-৩ গুণ rule ব্যবহার করে)?
4. প্রতিটা log entry যদি গড়ে ৩০০ bytes হয়, দৈনিক storage বৃদ্ধি কত (MB/GB এ)?
5. এই সংখ্যাগুলো দেখে তোমার কী মনে হয় — এই write load একটা single PostgreSQL instance handle করতে পারবে, নাকি আলাদা কিছু (queue, batch write) দরকার হতে পারে? এক লাইনে reasoning দাও।

প্রতিটা ধাপে তোমার assumption স্পষ্টভাবে লেখো — এটাই সবচেয়ে গুরুত্বপূর্ণ অংশ, শুধু চূড়ান্ত সংখ্যা না।

৭. Progress Ledger

=== PROGRESS LEDGER ===
Completed: 1.1, 1.2
Current: 1.3 — Back-of-the-envelope Estimation
TaskFlow state: single Express server + 1 Postgres, ~100 users
Terms learned: System Design, Scale/Scaling, Trade-off, Functional Requirement,
Non-functional Requirement, Scope, Back-of-the-envelope Estimation, High-Level Design,
Deep Dive, Black Box, DAU, QPS, Peak QPS, Order of Magnitude, Bandwidth
Weak spots: Functional/Non-functional এ solution/constraint গুলিয়ে ফেলা (উন্নতি হচ্ছে);
HLD তে UI-state কে component হিসেবে দেখানো (Lesson 1.2 এর exercise এ হয়েছিল) — নজরে রাখতে হবে
Next: 1.4 — Client-Server, HTTP/HTTPS, connection lifecycle, keep-alive, HTTP/2 vs HTTP/3
=======================

৮. পরের Lesson

Exercise করে পাঠাও — বিশেষভাবে দেখব তুমি assumption গুলো স্পষ্টভাবে বলছ কিনা, আর শেষ প্রশ্নে (#৫) সংখ্যা থেকে সিদ্ধান্তে পৌঁছাতে পারছ কিনা। রেডি হলে next লিখো — Lesson 1.4 তে যাব, যেখানে আমরা client-server communication এর একদম ভেতরে ঢুকব: HTTP কীভাবে কাজ করে, connection lifecycle কী, আর কেন HTTP/2 বা HTTP/3 এর মতো নতুন version এসেছে।