Requirements and Scope
box আঁকার আগে প্রশ্ন করো — কোনগুলো design বদলায়, কোনগুলো সময় নষ্ট; আর অস্পষ্ট ask-কে সংখ্যাসহ designable problem বানানোর কৌশল।
- •অস্পষ্ট একটা request (“একটা Twitter বানাও”) পেলে design শুরুর আগে কোন clarifying questions করবে — বলতে পারা।
- •কোন প্রশ্নটা পুরো architecture বদলায় (high-leverage) আর কোনটা সময় নষ্ট — আলাদা করা।
- •functional আর non-functional requirement গভীরে বোঝা, আর NFR-এ সবসময় একটা সংখ্যা বসানো।
- •scope ছোট করা: ২–৪টা core feature নিয়ে বাকিটা “out of scope for now” বলা — কেন এটা skill।
- •constraints আর assumptions আলাদা করা; assumption জোরে বলা ও লিখে রাখার অভ্যাস।
- •Day 1 — system design কী, latency vs throughput, functional vs non-functional-এর পরিচয়, ৫-ধাপি framework।
- •back-of-the-envelope estimation-এর ধারণা (DAU → QPS) — Day 1-এ ছুঁয়েছিলে।
- •কোনো নতুন tool লাগবে না; আজ পুরোটাই চিন্তা ও প্রশ্ন করার skill।
Stop — Ask Before You Design
box আঁকা নয়, design শুরু হয় clarifying questions দিয়ে।
কেউ এসে বললো: "একটা Twitter বানিয়ে দাও।" তুমি কি সঙ্গে সঙ্গে box আঁকা শুরু করবে? ভালো engineer করে না — আগে প্রশ্ন করে।
Day 1-এ design-এর ৫-ধাপি framework দেখেছিলে। আজ তার প্রথম ধাপটা — requirements — হাতে-কলমে চালাব: কোন প্রশ্নগুলো করবে, কোনগুলো সময় নষ্ট, vague ask-কে সংখ্যায় কীভাবে নামাবে।
ঠিকাদার "বাড়ি বানাও" শুনে ইট গাঁথে না — আগে জিজ্ঞেস করে কয় তলা, বাজেট কত, কয়জন থাকবে। requirements phase ঠিক সেই মাপ নেওয়া। পাঁচটা জিনিস নিজে নাড়াচাড়া করবে।
design scopeestablish it — before you draw anything
অস্পষ্ট prompt পেয়ে সঙ্গে সঙ্গে box-and-arrow আঁকা শুরু করা = সবচেয়ে কমন ভুল। আগে থামো, প্রশ্ন করো। interview-এর ৪৫ মিনিটের প্রথম ৩–১০ মিনিট এই ধাপেই যায় — কারণ ভুল requirement-এর উপর দাঁড়ানো design পুরোটাই ভুল দিকে যায়।
ঠিকাদার "একটা বাড়ি বানাও" শুনে ইট গাঁথা শুরু করে না — আগে জিজ্ঞেস করে কয় তলা, বাজেট কত, কয়জন থাকবে। মাপ না নিয়ে বানালে হয় ছোট হয়, নয় টাকা নষ্ট।
clarifying questionshigh-leverage vs time-waste
কারা user, কী কী core feature, কত DAU, read-heavy না write-heavy, latency কত লাগবে — এই প্রশ্নগুলোই design-কে আকার দেয়। কিন্তু সব প্রশ্ন সমান নয়: কয়েকটা পুরো architecture বদলায়, কয়েকটা এখন সময় নষ্ট। interrogate কোরো না — যে কয়টা সত্যিই matter করে সেগুলো করো।
রাফি junior dev — boss বললো "একটা notice board app বানাও"। রাফি আগে জিজ্ঞেস করে: "কয়জন ব্যবহার করবে? সবাই শুধু পড়বে, নাকি লিখবেও?" এই দুই প্রশ্নেই design অর্ধেক ঠিক হয়ে যায়।
Functional vs Non-Functional, Revisited
system কী করবে, বনাম কত ভালোভাবে করবে।
functionaltop ৩–৪টা feature — what it does
system আসলে কী কী করবে — feature আর কাজ (post a tweet, send a message, match a ride)। interview-এ top ৩–৪টা বাছো, ব্যস। লম্বা feature-list উল্টো ক্ষতি করে — দেখায় তুমি জরুরি আর শখের জিনিস আলাদা করতে পারো না।
food delivery app-এর functional শুরুতে তিনটাই যথেষ্ট: "খাবার order করা যাবে, order track করা যাবে, rating দেওয়া যাবে।" ১০টা feature গুনতে গেলে কোনোটাই গভীরে যাবে না।
non-functionalthe core four + domain extras
system কত ভালোভাবে করবে — quality attribute। core four: availability, scalability, latency, consistency। domain চাইলে যোগ হয় durability, security, compliance, cost। design-এর আসল খেলা এখানেই — আর এরা পরস্পরবিরোধী, সব একসাথে max হয় না, prioritize করতে হয়।
"order করা যাবে" সহজ অংশ। আসল চ্যালেঞ্জ: "ঈদের দিন ১০× চাপেও <2s-এ confirm দেবে, আর কখনো down হবে না।" এই non-functional শর্তগুলো মেটানোই design।
Every NFR Needs a Number
"fast" নয় — "<200ms p99"; আর প্রতিটা target-এর দাম আছে।
quantify/ measurable — needs a number
"fast" নয় — "search result < 500ms p99"। "scalable" নয় — "scale to 100M DAU"। প্রতিটা NFR-এ একটা সংখ্যা আর কোন operation-এর কথা বলছ সেটা থাকতে হবে — নাহলে design করাও যায় না, যাচাইও করা যায় না।
boss বললো "site-টা একটু fast করো" — অর্থহীন, কোথা থেকে শুরু করবে? কিন্তু "homepage ১ সেকেন্ডের নিচে load হবে" — এখন মাপা যায়, কাজ করা যায়। if you can't measure it, you can't design for it.
The Highest-Leverage Question, and Narrowing Scope
read-heavy না write-heavy · কম feature নিয়ে গভীরে যাও।
read-to-write ratioread-heavy vs write-heavy
প্রায়ই সবচেয়ে বেশি-leverage একটা প্রশ্ন: system read-heavy না write-heavy? read-heavy (Twitter, URL shortener — প্রায় 100:1) হলে cache, read replica, CDN লাগে। write-heavy বা balanced (chat — প্রায় 1:1) হলে একদম অন্য design। একটা সংখ্যা পুরো architecture-এর দিক ঠিক করে দেয়।
Daraz-এ মানুষ হাজারবার product দেখে, কেনে কম — ভীষণ read-heavy। তাই product page আগ্রাসীভাবে cache করা হয়; প্রতিবার database-এ গেলে peak-এ ভেঙে পড়বে।
in / out of scopeMVP / core features
২–৪টা core feature (MVP) নাও, বাকি সব জোরে বলে সরিয়ে রাখো — "DM, search এখন out of scope"। এটা শর্টকাট নয়, একটা পুরস্কৃত skill: scope ছোট রাখলে তবেই interesting অংশে গভীরে যাওয়া যায়, আর ৪৫ মিনিটে সময় ফুরায় না।
hackathon-এ ৩৬ ঘণ্টায় ১০টা feature ধরলে কিছুই দাঁড়ায় না; ২টা পরিষ্কার feature বানালে demo হয়। interview-ও ঠিক তাই — কম নিয়ে গভীরে যাও।
From Vague to Concrete
vague ask-কে সংখ্যাসহ designable problem বানানো + assumptions।
constraints& assumptions — say them aloud
constraints = বাস্তব সীমা যার ভেতরে design করো (200M DAU, বাজেট, GDPR/PCI compliance, পুরোনো stack)। assumptions = যে গ্যাপ interviewer বলে না, তুমি ধরে নাও — কিন্তু চুপচাপ নয়, জোরে বলো আর লিখে রাখো: “ধরে নিচ্ছি 100:1 read:write — ভুল হলে বলবেন।”
“ধরে নিচ্ছি শুধু বাংলাদেশে চলবে, একটা region” — জোরে বললে interviewer ভুল হলে শুধরে দেয়, আর তুমি আটকে না থেকে এগোতে পারো। assumption লুকিয়ে রাখলে পরে পুরো design বদলাতে হয়।
Check Your Understanding
ভুল করলেও সমস্যা নেই — প্রতিটার ব্যাখ্যা আছে।
"Design X করো" শুনলেই সঙ্গে সঙ্গে box-and-arrow আঁকা শুরু করব।
যত বেশি feature ধরব, interview-এ তত ভালো দেখাবে।
Non-functional requirement মানে "fast", "scalable" বললেই হলো।
সব clarifying question সমান গুরুত্বপূর্ণ।
সব NFR একসাথে সর্বোচ্চ করা যায়।
Read/write ratio একটা ছোট, গৌণ detail।
Assumption ধরে নেওয়া মানে অনুমানে কাজ করা — খারাপ ব্যাপার।
Capacity estimation সবসময় করতেই হবে।
"Design Twitter" শুনে প্রথম কাজ কোনটা?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
NFR (non-functional requirement) লেখার সোনালি নিয়ম কী?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
কোনটা functional requirement?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
প্রায়ই সবচেয়ে বেশি-leverage clarifying question কোনটা?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
Interview-এ ১০টা feature একসাথে ধরা — ভালো না খারাপ?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
Availability 99.9% থেকে 99.99%-এ গেলে কী বদলায়?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
Constraint আর assumption-এর পার্থক্য কী?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
"Availability over consistency" — কখন বেছে নেবে?
ভুল হলেও সমস্যা নেই — প্রতিটা option-এর সাথে ব্যাখ্যা আছে।
চারটে idea মনে রাখো — অস্পষ্ট ask পেয়ে সঙ্গে সঙ্গে box আঁকা নয়, আগে থামো ও clarifying questions করো; প্রতিটা non-functional requirement-এ একটা সংখ্যা বসাও, "fast/scalable" বললেই হয় না; read-heavy না write-heavy — এই এক প্রশ্নই cache/replica/CDN লাগবে কিনা পুরো architecture-এর দিক ঠিক করে দেয়; আর ২–৪টা core feature নিয়ে বাকিটা জোরে বলে "out of scope for now" রাখো — কম নিয়ে গভীরে যাওয়াই আসল skill।
শব্দার্থ — পরে ফিরে দেখার জন্য
একনজরে সব key term। কোনো শব্দ ভুলে গেলে এখানে এসে খুঁজে নিও।
- Assumptions
- interviewer যা বলে না, তুমি ধরে নাও — জোরে বলে ও লিখে রেখে।
- Availability
- system কত শতাংশ সময় চালু (99.9% = বছরে ~৮.৮ ঘণ্টা down; five nines = ~৫ মিনিট)।
- Clarifying questions
- design শুরুর আগে অস্পষ্ট request পরিষ্কার করতে যে প্রশ্নগুলো করো (users, features, scale, performance)।
- Compliance
- আইনি/নিয়ন্ত্রক বাধ্যবাধকতা — GDPR (data), PCI (card), HIPAA (health)।
- Consistency
- সব replica একই data দেখায় কিনা ও কখন — strong (banking) বনাম eventual (feed)।
- Constraints
- বাস্তব সীমা যার ভেতরে design করতে হয় (scale, বাজেট, compliance, পুরোনো stack)।
- Core features
- system-এর যে ২–৪টা feature ছাড়া সেটা অর্থহীন — বাকি সব পরে।
- DAU
- Daily Active Users — দিনে কতজন সত্যিকার user; scale বোঝার ভিত্তি।
- Design scope
- এই session-এ system-এর কতটুকু design করবে তার সীমানা — কী in, কী out।
- Durability
- একবার confirm-করা data আর কখনো হারায় না (payment = 100% durable)।
- Functional requirement
- system কী করবে — feature/কাজ (post, follow, send message)।
- In scope / out of scope
- যেটা এখন বানাবে (in) বনাম যেটা পরে/বাদ (out)। জোরে বলা একটা skill।
- Latency (p99)
- request-এর সময়; p99 = ১০০টার সবচেয়ে ধীর ১টা — average-এর চেয়ে সত্য বেশি বলে।
- MVP
- Minimum Viable Product — সবচেয়ে কম feature নিয়ে কাজ করা version; interview-এ top ২–৪টা।
- Non-functional requirement (NFR)
- system কত ভালোভাবে করবে — quality (fast, available, scalable, consistent), সংখ্যাসহ।
- QPS
- Queries Per Second — সেকেন্ডে কতগুলো request।
- Quantify
- NFR-কে মাপার যোগ্য করা — "fast" নয়, "<200ms p99"। মাপতে না পারলে design করা যায় না।
- Read-heavy / write-heavy
- system বেশি পড়ে নাকি বেশি লেখে — পুরো architecture-এর দিক ঠিক করে।
- Read-to-write ratio
- read আর write-এর অনুপাত (যেমন 100:1); read-heavy হলে cache/replica/CDN।
- Scalability
- চাপ বাড়লেও performance ধরে রাখা — সাধারণত horizontal scaling-এ।
Sources consulted to author this lesson. Citation style is informal — follow the links if you want to dig deeper.
- The System Design Primer — Step 1: Use cases, constraints, assumptions — Donne Martin (2023)
- A Framework for System Design Interviews — Step 1: Establish design scope — Alex Xu (ByteByteGo) (2023)
- System Design Delivery Framework — Requirements — Hello Interview (2024)
- Non-Functional Requirements (the core four) — System Design School (2024)
- Functional vs Non-Functional Requirements — System Design Handbook (2024)
দুই বাক্যে নিজের ভাষায় লেখো
তোমার বন্ধু বলছে: "একটা YouTube-এর মতো video app design করব।" দু'বাক্যে বলো — প্রথমে কোন দুটো clarifying question করবে (একটা যেন read/write ratio নিয়ে হয়), আর একটা non-functional requirement সংখ্যাসহ লেখো।