Senior Data Scientist বা Machine Learning Engineer interview-এ শুধু:
Which model would you use?
এই প্রশ্নের answer যথেষ্ট নয়।
আরও important প্রশ্ন হলো:
এই model production-এ millions of requests reliably কীভাবে serve করবে?
এখানেই ML System Design আসে।
প্রথমে Requirement বুঝুন
Architecture design করার আগে জানতে হবে:
Prediction কখন দরকার?
Latency কত?
Traffic কত?
Data কত fresh?
Model কত heavy?
Prediction কত frequently change হয়?
Failure হলে কী হবে?
এই answers architecture determine করে।
Latency
Latency হলো request আসার পর prediction return করতে কত সময় লাগে।
উদাহরণ:
Fraud transaction:
User payment করছে
↓
Fraud score দরকার
↓
Decision
এখানে হয়তো:
<100 ms
target থাকতে পারে।
অন্যদিকে nightly customer churn scoring:
2 hours
লাগলেও business problem নাও হতে পারে।
তাই:
Latency requirement problem-specific।
Throughput
Throughput হলো system প্রতি unit time-এ কত requests process করতে পারে।
সাধারণভাবে:
Requests Per Second — RPS
দিয়ে measure করা হয়।
উদাহরণ:
10 RPS
এর architecture এবং:
100,000 RPS
এর architecture এক হবে না।
Latency vs Throughput
দুটো related হলেও same না।
Latency
→ One request কত দ্রুত complete হয়?
Throughput
→ Total কত request process করতে পারি?
একটি system low latency হলেও limited throughput থাকতে পারে।
Batch Prediction
Batch architecture-এ predictions আগে থেকে calculate করা হয়।
উদাহরণ:
Every Night
↓
Generate Recommendations
↓
Store in Database / Cache
↓
Serve During Day
Use cases:
Daily Recommendation List
Churn Scoring
Marketing Segmentation
Demand Forecast
Risk Reports
Benefit
serving simple real-time feature computation কম expensive models offline run করা যায় prediction cache করা সহজ
Problem:
Prediction stale হতে পারে
Online Prediction
Online inference-এ request আসার সময় prediction generate করা হয়।
Example:
Transaction arrives
↓
Fetch latest features
↓
Fraud Model
↓
Fraud Score
Useful যখন:
Fresh Context
খুব important।
Examples:
Fraud Detection
Real-Time Ranking
Dynamic Pricing
Real-Time ETA
Trade-off
Online prediction:
Fresh
কিন্তু:
More Infrastructure Complexity
Higher Latency Risk
Online Feature Dependency
Batch vs Online
Batch
→ Precompute
→ Simple serving
→ Potentially stale
Online
→ Compute on request
→ Fresh
→ More complex
অনেক production system:
Hybrid
approach ব্যবহার করে।
Hybrid Example
Recommendation system:
Nightly:
Generate 500 candidates per user
Real Time:
Re-rank candidates using latest context
এতে batch efficiency এবং online freshness দুটোই পাওয়া যায়।
Caching
একই prediction বা computation repeatedly দরকার হলে cache useful।
Flow:
Request
↓
Check Cache
Found?
├── Yes → Return Quickly
└── No → Model Prediction
↓
Cache
↓
Return
Example
Restaurant recommendation একই user-এর জন্য প্রতি second-এ drastically change করে না।
তাই:
Recommendation List
কিছু সময় cache করা যেতে পারে।
Benefit:
latency কমে
model server load কমে
infrastructure cost কমে
Cache-এর Risk
Prediction কতক্ষণ valid?
এটাই:
TTL — Time To Live
choice।
TTL বেশি হলে stale result।
TTL খুব কম হলে cache benefit কম।
Horizontal Scaling
একটি model server traffic handle করতে না পারলে multiple replicas ব্যবহার করা যায়।
Load Balancer
/ | \
/ | \
Server 1 Server 2 Server 3
Traffic multiple instances-এ distribute হয়।
এটাকে horizontal scaling বলা হয়।
Autoscaling
Traffic সবসময় constant নয়।
Lunch time:
High Traffic
Midnight:
Low Traffic
Autoscaling demand অনুযায়ী instances increase/decrease করতে পারে।
Feature Availability
একটি model production-এ deploy করার আগে crucial প্রশ্ন:
Training-এর সময় যে features ব্যবহার করেছি, prediction time-এ সেগুলো কি available?
ধরুন fraud model feature:
Customer's final monthly spending
কিন্তু real-time transaction-এর সময় final monthly spending এখনও জানা যায়নি।
তাহলে feature production-safe নয়।
Feature Store
Large ML system-এ features centrally manage করার জন্য feature store ব্যবহার করা যেতে পারে।
Goal:
Consistent Feature Definitions
Reusable Features
Offline + Online Access
Versioning
এটি train-serving skew reduce করতেও সাহায্য করতে পারে।
Monitoring
Scalable system শুধু request serve করলেই যথেষ্ট নয়।
Need monitor:
Latency
Throughput
Error Rate
CPU
Memory
GPU
Feature Availability
Input Drift
Prediction Drift
Model Performance
Business KPI
কেন শুধু Model Metric নয়?
ধরুন model accuracy fine।
কিন্তু:
P99 Latency = 3 seconds
তাহলে user experience poor হতে পারে।
অথবা:
Prediction API Error Rate = 10%
তাহলে model quality irrelevant হয়ে যায়।
Fallback
ML model বা feature service fail করলে system কী করবে?
Example:
Recommendation Model Fails
↓
Fallback
↓
Popular Items
ETA model fails:
Fallback
→ Rule-based ETA
Fraud model unavailable:
Fallback
→ Rule Engine
Production system-এ graceful degradation important।
Scalability শুধু More Servers নয়
Scalable ML design বলতে শুধু:
Add more machines
বোঝায় না।
এর মধ্যে থাকে:
Batching
Caching
Load Balancing
Horizontal Scaling
Efficient Features
Model Optimization
Approximate Search
Async Processing
Data Partitioning
Fallbacks
Monitoring
Example Design
ধরুন personalized recommendation system:
User Request
↓
API Gateway
↓
Feature / User Context
↓
Candidate Retrieval
↓
Ranking Model
↓
Business Rules
↓
Top-N Results
↓
Cache
↓
User
এখন প্রতিটি stage-এর জন্য প্রশ্ন করতে হবে:
Latency কত?
Failure হলে কী হবে?
Traffic কত?
Cache করা যাবে?
Feature কোথা থেকে আসবে?
Model কত frequently update হবে?
এটাই production ML system thinking।
Interview-ready Explanation
Designing a scalable ML system requires more than choosing
a good model.
I would first define latency, throughput, freshness,
availability, and cost requirements.
Then I would decide whether predictions should be batch,
online, or hybrid.
For high traffic, techniques such as caching, load balancing,
horizontal scaling, autoscaling, and efficient feature
retrieval may be required.
I would also monitor system metrics, data drift, model
performance, and business KPIs.
Finally, production systems should have a fallback so that
the application can continue operating even if the model
or one of its dependencies fails.
সহজে মনে রাখুন:
Scalable ML System
=
Good Model
+
Fast Serving
+
Reliable Features
+
Enough Capacity
+
Monitoring
+
Fallback
+
Business Value