Tech lead તરીકે વપરાશકર્તા દસ ગણાં વધે તેની તૈયારી કેવી રીતે કરશો?

Question

IT Interview Practice · Accepted Answer

Tech lead તરીકે હું પહેલાં **“દસ ગણા users”ને અપેક્ષિત ઉપયોગ, service targets અને ટીમ પૂરી કરી શકે એવા પ્લાનમાં ફેરવું**. Registered accountsની સંખ્યા એકલી સૌથી વ્યસ્ત સમયે કેટલા requests આવશે તે કહેતી નથી.

માનો કે વ્યવસાય order platform માટે campaign ગોઠવે છે. પ્રશ્ન એ છે કે ઉપલબ્ધ સમય અને budgetમાં campaign દરમિયાન customers browse, buy અને confirmation મેળવી શકશે કે નહીં.

## 1. વૃદ્ધિને workloadમાં ફેરવો

Product ટીમને પૂછો users ક્યારે આવશે અને કઈ ક્રિયાઓ કરશે. એક વર્ષમાં ધીમો વધારો અને બધાને એકસાથે online લાવતી campaign જુદી છે.

ઉદાહરણ તરીકે, 100,000 registered accountsમાંથી 1% એકસાથે active હોય તો 1,000 concurrent users થાય. 5% હોય તો 5,000. આ ઉદાહરણના અનુમાન છે, default ratio નહીં. Request frequency અને દરેક requestનું કામ પણ ગણવું પડે.

Campaign બનાવતો ભાર લખો:

- Browse અને search requests, લોકપ્રિય products સહિત.
- Peak સમયે order અને payment writes.
- વધતું storage અને સાચવેલો ઇતિહાસ.
- Notifications અને reports જેવું background કામ.

એથી server દસ ગણા કરવાની અસ્પષ્ટ સૂચનાને બદલે તપાસી શકાય એવો workload મળે છે.

## 2. શું સારું રહેવું જ જોઈએ તે નક્કી કરો

Critical journeys માટે સ્વીકાર્ય response time, error rate અને completion નક્કી કરો. જ્યાં જરૂરી હોય ત્યાં data freshness અને recoveryની અપેક્ષા પણ નક્કી કરો. Report મોડો મળે તે ચાલે, પરંતુ checkout નિષ્ફળ જાય તે ન ચાલે.

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

આ targets technical કામને customer outcomes સાથે જોડે છે. તે બતાવે છે કે સુધારો પૂરતો છે કે નહીં અને દબાણ હેઠળ કઈ service degradation સ્વીકાર્ય છે.

## 3. ફેરફાર પસંદ કરતાં પહેલાં હાલની મર્યાદા માપો

Production observations અને પ્રતિનિધિ load tests વાપરો. Slow queries, database connections, CPU, memory, queue age અને external-service quotas તપાસો. માત્ર random requests નહીં, લોકપ્રિય વસ્તુઓ પર અસમાન traffic પણ સામેલ કરો.

Database connections મર્યાદા હોય તો application nodes વધારવાથી contention વધી શકે. Payment providerનો quota મર્યાદા હોય તો ઝડપી application તે quota વધારતું નથી.

સામાન્ય સ્થિતિ સાથે cold cache અને એક instance ગુમાવવાની સ્થિતિ પણ તપાસો. Campaign દરમિયાન recovery કરવાની ક્ષમતા જોઈએ, માત્ર આદર્શ test run માટે પૂરતી capacity નહીં.

## 4. તારણોને જવાબદાર વ્યક્તિ ધરાવતા કામમાં ફેરવો

| તારણ | સંભવિત પગલું | જરૂરી પુરાવો |
| --- | --- | --- |
| વારંવાર ખર્ચાળ reads | Query સુધારો અથવા યોગ્ય results cache કરો | સ્વીકાર્ય freshness સાથે ઓછું database કામ. |
| Background tasks ખરીદી સાથે સ્પર્ધા કરે છે | તેમની capacity મર્યાદિત અથવા અલગ કરો | Background load દરમિયાન checkout સ્વસ્થ રહે. |
| Dependency quota ઓછો છે | વધારો મેળવો અથવા admission નિયંત્રિત કરો | Confirmed quota અને limit પર તપાસેલું વર્તન. |
| નાના સુધારા પછી પણ capacity ઓછી છે | Scaling અથવા મોટો design change તપાસો | માપેલો લાભ, migration plan અને ખર્ચ. |

દરેક actionને owner, budget, dependencies, due date અને acceptance test આપો. માત્ર implementation નહીં, deployment, operational training અને on-call તૈયારી પણ સામેલ કરો.

Customer impact અને delivery risk પ્રમાણે પ્રાથમિકતા આપો. મોટા rewrite કે sharding project માટે સાબિત કારણ તથા migration અને verification માટે પૂરતો સમય જોઈએ.

## 5. Campaignનું rehearsal કરો અને traffic ધીમે વધારો

ફેરફારો સંભાળી શકાય એવા ભાગમાં release કરો અને અપેક્ષિત journeys સાથે તપાસો. Traffic ક્યારે વધારવો, વધારો અટકાવવો કે rollback કરવો તે નક્કી કરો. Data format બદલાય તો સરળ rollbackને બદલે આગળનો સુધારો જરૂરી હોઈ શકે.

નિયંત્રિત degradation તૈયાર રાખો: optional exports મોડા કરો, background કામ મર્યાદિત કરો અથવા critical operations બચાવી વધારાના requests નકારો. આ પગલાં ખરેખર ભાર ઘટાડે છે અને customerને સ્પષ્ટ પરિણામ આપે છે તે તપાસો.

Target સમય કે budgetમાં ન બેસે તો productને ચોક્કસ વિકલ્પ આપો: acquisition તબક્કામાં કરો, ખર્ચાળ feature ઘટાડો અથવા માપેલા bottleneck માટે ભંડોળ આપો. દરેક વિકલ્પની customer અસર અને અનિશ્ચિતતા સમજાવો.

**યાદ રાખો:** growth assumptions → service targets → measured limits → જવાબદારીવાળો roadmap → rehearsal કરેલો rollout. Tech leadના capacity planમાં લોકો, પૈસા અને recovery પણ આવે છે.

તારણ	સંભવિત પગલું	જરૂરી પુરાવો
વારંવાર ખર્ચાળ reads	Query સુધારો અથવા યોગ્ય results cache કરો	સ્વીકાર્ય freshness સાથે ઓછું database કામ.
Background tasks ખરીદી સાથે સ્પર્ધા કરે છે	તેમની capacity મર્યાદિત અથવા અલગ કરો	Background load દરમિયાન checkout સ્વસ્થ રહે.
Dependency quota ઓછો છે	વધારો મેળવો અથવા admission નિયંત્રિત કરો	Confirmed quota અને limit પર તપાસેલું વર્તન.
નાના સુધારા પછી પણ capacity ઓછી છે	Scaling અથવા મોટો design change તપાસો	માપેલો લાભ, migration plan અને ખર્ચ.

1. વૃદ્ધિને workloadમાં ફેરવો

2. શું સારું રહેવું જ જોઈએ તે નક્કી કરો

3. ફેરફાર પસંદ કરતાં પહેલાં હાલની મર્યાદા માપો

4. તારણોને જવાબદાર વ્યક્તિ ધરાવતા કામમાં ફેરવો

5. Campaignનું rehearsal કરો અને traffic ધીમે વધારો

સંબંધિત પ્રશ્નો