Tech lead‌గా వినియోగదారులు పది రెట్లు పెరిగేందుకు ఎలా ప్రణాళిక వేస్తారు?

Question

IT Interview Practice · Accepted Answer

Tech lead గా ముందుగా **“పది రెట్లు ఎక్కువ వినియోగదారులు” అనేదాన్ని ఆశించే వినియోగం, service targets, బృందం అందించగల ప్రణాళికగా** మారుస్తాను. Registered accounts సంఖ్య మాత్రమే అత్యంత రద్దీ సమయంలో ఎన్ని requests వస్తాయో చెప్పదు.

ఒక order platform కోసం business campaign ప్లాన్ చేస్తోందనుకుందాం. అందుబాటులో ఉన్న సమయం, budget లో campaign సమయంలో కూడా customers browse చేసి, కొనుగోలు చేసి, confirmation పొందగలరా అనేది ప్రశ్న.

## 1. వృద్ధిని workload గా మార్చండి

Users ఎప్పుడు వస్తారు, ఏ చర్యలు చేస్తారు అని product బృందాన్ని అడగండి. ఏడాదిపాటు క్రమమైన పెరుగుదల, అందరూ ఒకేసారి online వచ్చే campaign కి భిన్నం.

ఉదాహరణకు 100,000 registered accounts లో 1% ఒకేసారి active అయితే 1,000 concurrent users. 5% అయితే 5,000. ఇవి ఉదాహరణ అంచనాలు, సాధారణ నిష్పత్తులు కావు. Request frequency, ప్రతి request చేసే పని ఇంకా అంచనా వేయాలి.

Campaign సృష్టించే load ను జాబితా చేయండి:

- ప్రజాదరణ ఉన్న products సహా browsing, search requests.
- Peak సమయంలో order, payment writes.
- పెరిగే storage, నిల్వ చేసే history.
- Notifications, reports వంటి background work.

Server సంఖ్యను పది రెట్లు చేయాలనే అస్పష్ట సూచనకు బదులుగా పరీక్షించగల workloads వస్తాయి.

## 2. ఏవి బాగా కొనసాగాలో అంగీకరించండి

కీలక customer journeys కోసం ఆమోదయోగ్యమైన response time, error rate, completion ను నిర్వచించండి. అవసరమైన చోట data freshness, recovery ఆశలను కూడా నిర్వచించండి. Report ఆలస్యం ఆమోదయోగ్యమైనా checkout విఫలం కావడం కాకపోవచ్చు.

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

Targets సాంకేతిక పనిని customer outcomes తో అనుసంధానిస్తాయి. మెరుగుదల సరిపోతుందా, ఒత్తిడిలో ఏ నాణ్యత తగ్గుదల సహించవచ్చు అనేది నిర్ణయించడంలో సహాయపడతాయి.

## 3. మార్పులు ఎంచుకునే ముందు ప్రస్తుత పరిమితిని కొలవండి

Production పరిశీలనలు, representative load tests ఉపయోగించండి. Slow queries, database connections, CPU, memory, queue age, external-service quotas పరిశీలించండి. Random requests మాత్రమే కాక popular items పై అసమాన traffic చేర్చండి.

Database connections పరిమితి అయితే application nodes పెంచడం contention పెంచవచ్చు. Payment provider quota పరిమితి అయితే వేగమైన application ఆ quota ను పెంచదు.

సాధారణ operation తోపాటు cold caches, ఒక instance కోల్పోవడాన్ని పరీక్షించండి. ఆదర్శ test run కోసం మాత్రమే కాక campaign లో recovery కోసం కూడా capacity కావాలి.

## 4. కనుగొన్న అంశాలను బాధ్యత కేటాయించిన పనులుగా మార్చండి

| కనుగొన్నది | పరిశీలించే చర్య | అవసరమైన ఆధారం |
| --- | --- | --- |
| పదేపదే ఖరీదైన reads | Query మెరుగుపరచడం లేదా తగిన results cache చేయడం | ఆమోదయోగ్య freshness తో database పని తగ్గడం. |
| Background tasks కొనుగోళ్లతో పోటీపడటం | వాటి capacity పరిమితం చేయడం లేదా విడదీయడం | Background load లో checkout సక్రమంగా ఉండటం. |
| Dependency quota సరిపోకపోవడం | పెంపు ఏర్పాటు చేయడం లేదా admission నియంత్రించడం | నిర్ధారించిన quota, పరిమితి వద్ద పరీక్షించిన ప్రవర్తన. |
| చిన్న fixes తర్వాత కూడా capacity చాలకపోవడం | Scaling లేదా పెద్ద design మార్పు పరిశీలించడం | కొలిచిన ప్రయోజనం, migration plan, ఖర్చు. |

ప్రతి చర్యకు బాధ్యుడు, budget, dependencies, గడువు, acceptance test ఇవ్వండి. Implementation తోపాటు deployment పని, operational training, on-call సిద్ధత చేర్చండి.

Customer impact, delivery risk ఆధారంగా ప్రాధాన్యం ఇవ్వండి. పెద్ద rewrite లేదా sharding కు నిరూపిత కారణం, migration మరియు verification కోసం తగిన సమయం అవసరం.

## 5. Campaign రిహార్సల్ చేసి traffic క్రమంగా పెంచండి

నిర్వహించగల దశల్లో మార్పులు విడుదల చేసి expected journeys ను కలిపి పరీక్షించండి. Traffic ఎప్పుడు పెంచాలి, పెంపును ఆపాలి, rollback చేయాలి అనేది నిర్వచించండి. Data-format మార్పులకు సులభ rollback బదులు forward recovery అవసరమవవచ్చు.

నియంత్రిత degradation సిద్ధం చేయండి: optional exports ఆలస్యం చేయడం, background work కు పరిమితి పెట్టడం లేదా critical operations కాపాడుతూ అదనపు requests నిరాకరించడం. ఇవి నిజంగా load తగ్గిస్తాయనీ customers కు స్పష్టమైన ఫలితం వస్తుందనీ పరీక్షించండి.

Target తేదీ లేదా budget కి సరిపోకపోతే product కి స్పష్టమైన ఎంపికలు ఇవ్వండి: users ను దశలుగా తీసుకురావడం, ఖరీదైన feature తగ్గించడం లేదా కొలిచిన bottleneck కు నిధులు ఇవ్వడం. ప్రతి ఎంపికలో customer impact, uncertainty వివరించండి.

**గుర్తుంచుకోండి:** growth assumptions → service targets → measured limits → బాధ్యతలతో roadmap → రిహార్సల్ చేసిన rollout. Tech lead మనుషులు, డబ్బు, recovery కలిగిన capacity plan అందిస్తారు.

కనుగొన్నది	పరిశీలించే చర్య	అవసరమైన ఆధారం
పదేపదే ఖరీదైన reads	Query మెరుగుపరచడం లేదా తగిన results cache చేయడం	ఆమోదయోగ్య freshness తో database పని తగ్గడం.
Background tasks కొనుగోళ్లతో పోటీపడటం	వాటి capacity పరిమితం చేయడం లేదా విడదీయడం	Background load లో checkout సక్రమంగా ఉండటం.
Dependency quota సరిపోకపోవడం	పెంపు ఏర్పాటు చేయడం లేదా admission నియంత్రించడం	నిర్ధారించిన quota, పరిమితి వద్ద పరీక్షించిన ప్రవర్తన.
చిన్న fixes తర్వాత కూడా capacity చాలకపోవడం	Scaling లేదా పెద్ద design మార్పు పరిశీలించడం	కొలిచిన ప్రయోజనం, migration plan, ఖర్చు.

1. వృద్ధిని workload గా మార్చండి

2. ఏవి బాగా కొనసాగాలో అంగీకరించండి

3. మార్పులు ఎంచుకునే ముందు ప్రస్తుత పరిమితిని కొలవండి

4. కనుగొన్న అంశాలను బాధ్యత కేటాయించిన పనులుగా మార్చండి

5. Campaign రిహార్సల్ చేసి traffic క్రమంగా పెంచండి

సంబంధిత ప్రశ్నలు