Tech lead হিসেবে ব্যবহারকারী দশ গুণ বৃদ্ধির পরিকল্পনা কীভাবে করবেন?

Question

IT Interview Practice · Accepted Answer

Tech lead হিসেবে প্রথমে আমি **“দশ গুণ ব্যবহারকারী”কে প্রত্যাশিত ব্যবহার, service target এবং দল বাস্তবায়ন করতে পারে এমন পরিকল্পনায় রূপ দেব**। শুধু registered account দিয়ে ব্যস্ততম সময়ে কত request আসে জানা যায় না।

ধরুন ব্যবসা একটি order platform-এর campaign পরিকল্পনা করছে। প্রশ্ন হলো উপলব্ধ সময় ও budget-এর মধ্যে campaign চলাকালে গ্রাহক browse, buy এবং confirmation পেতে পারবেন কি না।

## 1. Growth-কে workload-এ রূপ দিন

Product-কে জিজ্ঞেস করুন ব্যবহারকারী কখন আসবেন এবং কী করবেন। এক বছরে ধীরে বাড়া আর সবাইকে একসঙ্গে আনা campaign আলাদা।

উদাহরণস্বরূপ, 100,000 registered account-এর 1% একই সময়ে active হলে 1,000 concurrent user। 5% হলে 5,000। এগুলো উদাহরণের অনুমান, default ratio নয়। Request frequency ও প্রতি request-এর কাজ এখনও হিসাব করতে হবে।

Campaign যে load তৈরি করে তা লিখুন:

- Browse ও search request, জনপ্রিয় পণ্যসহ।
- Peak time-এ order ও payment write।
- বাড়তে থাকা storage ও সংরক্ষিত history।
- Notification ও report-এর মতো background work।

এতে server সংখ্যা দশ গুণ করার অস্পষ্ট নির্দেশের বদলে পরীক্ষা করার workload পাওয়া যায়।

## 2. কী ভালো থাকতে হবে একমত হন

গুরুত্বপূর্ণ journey-র গ্রহণযোগ্য response time, error rate ও completion নির্ধারণ করুন। যেখানে প্রাসঙ্গিক সেখানে freshness ও recovery expectation-ও ঠিক করুন। Report দেরি চলতে পারে, failed checkout নয়।

```text
[Campaign assumptions] -> [Expected workload] -> [Service targets]
                                                   |
                                            [Acceptance tests]
```

Target প্রযুক্তিগত কাজকে গ্রাহকের ফলের সঙ্গে যুক্ত করে। এতে উন্নতি যথেষ্ট কি না এবং চাপে কোন degradation গ্রহণযোগ্য তা ঠিক করা যায়।

## 3. পরিবর্তন বাছার আগে বর্তমান সীমা মাপুন

Production observation ও প্রতিনিধিত্বমূলক load test ব্যবহার করুন। Slow query, database connection, CPU, memory, queue age ও external-service quota দেখুন। শুধু random request নয়, জনপ্রিয় item-এ অসম traffic-ও রাখুন।

Database connection সীমা হলে application node যোগ করলে contention বাড়তে পারে। Payment provider-এর quota সীমা হলে দ্রুত application সেই quota বাড়ায় না।

স্বাভাবিক অবস্থার পাশাপাশি cold cache ও একটি instance হারানো পরীক্ষা করুন। Campaign চলাকালে recover করার capacity চাই, শুধু আদর্শ test run-এর জন্য যথেষ্ট capacity নয়।

## 4. পর্যবেক্ষণকে দায়িত্বপ্রাপ্ত কাজে রূপ দিন

| পর্যবেক্ষণ | সম্ভাব্য পদক্ষেপ | প্রয়োজনীয় প্রমাণ |
| --- | --- | --- |
| ব্যয়বহুল read বারবার হয় | Query উন্নত বা উপযুক্ত result cache | গ্রহণযোগ্য freshness-সহ database কাজ কমা। |
| Background task কেনাকাটার সঙ্গে প্রতিযোগিতা করে | তাদের capacity সীমিত বা আলাদা | Background load-এ checkout সুস্থ থাকা। |
| Dependency quota অপর্যাপ্ত | বাড়ানোর ব্যবস্থা বা admission control | নিশ্চিত quota ও সীমায় পরীক্ষিত আচরণ। |
| ছোট fix-এর পরও capacity কম | Scaling বা বড় design change বিবেচনা | মাপা সুবিধা, migration plan ও খরচ। |

প্রতিটি কাজের owner, budget, dependency, due date ও acceptance test দিন। শুধু implementation নয়, deployment, operational training ও on-call প্রস্তুতি ধরুন।

Customer impact ও delivery risk অনুযায়ী অগ্রাধিকার দিন। বড় rewrite বা sharding project-এর প্রমাণিত কারণ এবং migration ও verification-এর সময় দরকার।

## 5. Campaign-এর মহড়া এবং ধীরে traffic বাড়ান

পরিচালনাযোগ্য ধাপে release করুন এবং প্রত্যাশিত journey একসঙ্গে পরীক্ষা করুন। কখন traffic বাড়াবেন, থামাবেন বা rollback করবেন ঠিক করুন। Data format বদলালে সহজ rollback-এর বদলে forward recovery লাগতে পারে।

নিয়ন্ত্রিত degradation তৈরি করুন: optional export দেরি করান, background work সীমিত করুন বা critical operation রেখে অতিরিক্ত request প্রত্যাখ্যান করুন। নিয়ন্ত্রণগুলো সত্যিই load কমায় এবং গ্রাহক স্পষ্ট ফল পান কি না দেখুন।

Target সময় বা budget-এ না ধরলে product-কে বাস্তব বিকল্প দিন: acquisition ধাপে করা, ব্যয়বহুল feature কমানো বা মাপা bottleneck-এ অর্থ দেওয়া। প্রতিটির customer impact ও অনিশ্চয়তা বোঝান।

**মনে রাখুন:** growth assumption → service target → মাপা সীমা → owner-সহ roadmap → মহড়া দেওয়া rollout। Tech lead মানুষ, অর্থ ও recovery-সহ capacity plan দেন।

পর্যবেক্ষণ	সম্ভাব্য পদক্ষেপ	প্রয়োজনীয় প্রমাণ
ব্যয়বহুল read বারবার হয়	Query উন্নত বা উপযুক্ত result cache	গ্রহণযোগ্য freshness-সহ database কাজ কমা।
Background task কেনাকাটার সঙ্গে প্রতিযোগিতা করে	তাদের capacity সীমিত বা আলাদা	Background load-এ checkout সুস্থ থাকা।
Dependency quota অপর্যাপ্ত	বাড়ানোর ব্যবস্থা বা admission control	নিশ্চিত quota ও সীমায় পরীক্ষিত আচরণ।
ছোট fix-এর পরও capacity কম	Scaling বা বড় design change বিবেচনা	মাপা সুবিধা, migration plan ও খরচ।

1. Growth-কে workload-এ রূপ দিন

2. কী ভালো থাকতে হবে একমত হন

3. পরিবর্তন বাছার আগে বর্তমান সীমা মাপুন

4. পর্যবেক্ষণকে দায়িত্বপ্রাপ্ত কাজে রূপ দিন

5. Campaign-এর মহড়া এবং ধীরে traffic বাড়ান

সম্পর্কিত প্রশ্ন