Tech lead के रूप में users दस गुना बढ़ने की योजना कैसे बनाएँगे?

Question

IT Interview Practice · Accepted Answer

Tech lead के रूप में मैं पहले **“दस गुना users” को अपेक्षित उपयोग, service targets और team के पूरा कर सकने वाले plan में बदलूंगा**। केवल registered accounts की संख्या सबसे व्यस्त समय के requests नहीं बताती।

मान लें business order platform के लिए campaign बना रहा है। सवाल यह है कि उपलब्ध समय और budget में campaign के दौरान customers browse, buy और confirmation पा सकेंगे या नहीं।

## 1. Growth को workload में बदलें

Product से पूछें users कब आएंगे और क्या करेंगे। पूरे साल धीरे बढ़ना और एक campaign में सभी का साथ आना अलग हैं।

उदाहरण के लिए 100,000 registered accounts में 1% साथ active हों तो 1,000 concurrent users हैं। 5% हों तो 5,000। ये उदाहरण की assumptions हैं, default ratios नहीं। Request frequency और हर request का काम भी अनुमानित करना होगा।

Campaign का load लिखें:

- Browsing और search requests, लोकप्रिय products सहित।
- Peak times पर order और payment writes।
- बढ़ता storage और रखा हुआ इतिहास।
- Notifications और reports जैसा background work।

इससे servers दस गुने करने की अस्पष्ट बात के बजाय जांचने योग्य workloads मिलते हैं।

## 2. तय करें कि क्या अच्छा रहना जरूरी है

Critical journeys के लिए स्वीकार्य response time, error rate और completion तय करें। जहां महत्वपूर्ण हो, data freshness और recovery expectations भी तय करें। Report का delay स्वीकार्य हो सकता है, failed checkout नहीं।

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

Targets technical work को customer outcomes से जोड़ते हैं। इनसे पता चलता है कि सुधार पर्याप्त है या नहीं और दबाव में कौन-सी degradation स्वीकार की जा सकती है।

## 3. बदलाव चुनने से पहले मौजूदा सीमा मापें

Production observations और representative load tests लें। Slow queries, database connections, CPU, memory, queue age और external-service quotas देखें। केवल random requests नहीं, लोकप्रिय items पर असमान traffic भी शामिल करें।

Database connections सीमा हों तो application nodes जोड़ने से contention बढ़ सकता है। Payment provider quota सीमा हो तो तेज application उस quota को नहीं बढ़ाता।

Normal operation के साथ cold caches और instance loss भी जांचें। Campaign के दौरान recover करने की capacity चाहिए, केवल आदर्श test run जितनी नहीं।

## 4. निष्कर्षों को जिम्मेदारी वाले काम में बदलें

| निष्कर्ष | संभावित कदम | जरूरी प्रमाण |
| --- | --- | --- |
| बार-बार महंगे reads | Query सुधारें या उचित results cache करें | स्वीकार्य freshness के साथ कम database work। |
| Background tasks खरीदारी से संसाधन छीनते हैं | उनकी capacity सीमित या अलग करें | Background load के दौरान checkout स्वस्थ रहे। |
| Dependency quota कम है | बढ़ोतरी लें या admission नियंत्रित करें | Confirmed quota और limit पर tested behavior। |
| छोटे सुधारों के बाद भी capacity कम है | Scaling या बड़ा design change परखें | मापा लाभ, migration plan और cost। |

हर action को owner, budget, dependencies, due date और acceptance test दें। Implementation के साथ deployment, operational training और on-call तैयारी भी जोड़ें।

Customer impact और delivery risk से priority तय करें। बड़े rewrite या sharding project के लिए साबित कारण और migration तथा verification का पर्याप्त समय जरूरी है।

## 5. Campaign का rehearsal करें और traffic धीरे बढ़ाएं

Changes को संभालने योग्य हिस्सों में release करें और अपेक्षित journeys साथ जांचें। Traffic बढ़ाने, रोकने या rollback के नियम तय करें। Data-format changes में आसान rollback के बजाय forward recovery जरूरी हो सकती है।

Controlled degradation तैयार रखें: optional exports रोकें, background work सीमित करें या critical operations बचाते हुए अतिरिक्त requests नकारें। देखें कि controls सच में load घटाते हैं और customers को स्पष्ट outcome मिलता है।

Target तारीख या budget में न आए तो product को ठोस विकल्प दें: acquisition चरणों में करें, महंगा feature कम करें या मापे bottleneck पर खर्च करें। हर विकल्प का customer impact और uncertainty बताएं।

**याद रखें:** growth assumptions → service targets → measured limits → जिम्मेदारी वाला roadmap → rehearsed rollout। Tech lead के capacity plan में लोग, पैसा और recovery शामिल हैं।

निष्कर्ष	संभावित कदम	जरूरी प्रमाण
बार-बार महंगे reads	Query सुधारें या उचित results cache करें	स्वीकार्य freshness के साथ कम database work।
Background tasks खरीदारी से संसाधन छीनते हैं	उनकी capacity सीमित या अलग करें	Background load के दौरान checkout स्वस्थ रहे।
Dependency quota कम है	बढ़ोतरी लें या admission नियंत्रित करें	Confirmed quota और limit पर tested behavior।
छोटे सुधारों के बाद भी capacity कम है	Scaling या बड़ा design change परखें	मापा लाभ, migration plan और cost।

1. Growth को workload में बदलें

2. तय करें कि क्या अच्छा रहना जरूरी है

3. बदलाव चुनने से पहले मौजूदा सीमा मापें

4. निष्कर्षों को जिम्मेदारी वाले काम में बदलें

5. Campaign का rehearsal करें और traffic धीरे बढ़ाएं

संबंधित प्रश्न