Come prepararsi a dieci volte più utenti come tech lead?

Question

IT Interview Practice · Accepted Answer

Come tech lead, trasformerei prima **“dieci volte più utenti” in utilizzo previsto, obiettivi di servizio e un piano realizzabile dal team**. I soli account registrati non indicano quante richieste arriveranno nel momento di picco.

Supponiamo che l'azienda pianifichi una campagna per una piattaforma di ordini. La domanda è se i clienti potranno ancora navigare, acquistare e ricevere conferma durante la campagna, nei tempi e nel budget disponibili.

## 1. Traduci la crescita in carico di lavoro

Chiedi al team prodotto quando arriveranno gli utenti e quali azioni svolgeranno. Una crescita graduale in un anno è diversa da una campagna che porta tutti online nello stesso momento.

A titolo illustrativo, 100.000 account registrati con l'1% attivo simultaneamente significano 1.000 utenti concorrenti. Con il 5%, diventano 5.000. Sono ipotesi di esempio, non percentuali predefinite. Vanno comunque stimate frequenza delle richieste e lavoro per richiesta.

Elenca il carico creato dalla campagna:

- Richieste di navigazione e ricerca, inclusi i prodotti popolari.
- Scritture di ordini e pagamenti nei momenti di picco.
- Crescita dello storage e dello storico conservato.
- Lavoro in background, come notifiche e report.

Otteniamo così carichi da provare, invece di una vaga istruzione a moltiplicare i server per dieci.

## 2. Concorda cosa deve mantenere una buona qualità

Definisci tempi di risposta, tasso di errore e completamento accettabili per i percorsi critici. Definisci anche aggiornamento dei dati e aspettative di recupero dove contano. Un report in ritardo può essere accettabile, un checkout fallito no.

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

Gli obiettivi collegano il lavoro tecnico ai risultati per i clienti. Permettono di decidere se un miglioramento è sufficiente e quali degradazioni tollerare sotto pressione.

## 3. Misura il limite attuale prima di scegliere le modifiche

Usa osservazioni di produzione e test di carico rappresentativi. Esamina query lente, connessioni al database, CPU, memoria, anzianità dei job in coda e quote dei servizi esterni. Includi traffico sbilanciato sui prodotti popolari, non soltanto richieste casuali.

Se il limite sono le connessioni al database, aggiungere nodi applicativi può aumentare la contesa. Se il limite è la quota del fornitore di pagamenti, un'applicazione più veloce non aumenta quella quota.

Prova cache vuote e perdita di un'istanza, oltre al normale funzionamento. Serve capacità di recuperare durante la campagna, non soltanto quanto basta per un test ideale.

## 4. Trasforma le osservazioni in attività con responsabili

| Osservazione | Azione da valutare | Evidenza richiesta |
| --- | --- | --- |
| Letture costose ripetute | Migliorare la query o memorizzare risultati adatti in cache | Meno lavoro nel database con aggiornamento accettabile. |
| Task in background competono con gli acquisti | Limitarne o separarne la capacità | Checkout sano durante il carico in background. |
| Quota di una dipendenza insufficiente | Concordare un aumento o controllare l'ammissione | Quota confermata e comportamento al limite verificato. |
| Capacità ancora insufficiente dopo interventi minori | Valutare scaling o un cambiamento architetturale maggiore | Beneficio misurato, piano di migrazione e costo. |

Assegna a ogni azione responsabile, budget, dipendenze, scadenza e test di accettazione. Includi deployment, formazione operativa e preparazione della reperibilità, oltre all'implementazione.

Ordina le priorità per impatto sui clienti e rischio di consegna. Una grande riscrittura o un progetto di sharding richiede una motivazione dimostrata e tempo sufficiente per migrazione e verifica.

## 5. Simula la campagna e aumenta gradualmente il traffico

Rilascia modifiche in incrementi gestibili e prova insieme i percorsi previsti. Definisci quando aumentare il traffico, fermare l'espansione o effettuare un rollback. Le modifiche ai formati dei dati possono richiedere un recupero in avanti invece di un semplice ritorno alla versione precedente.

Prepara una degradazione controllata: ritarda esportazioni facoltative, limita il lavoro in background o rifiuta richieste in eccesso preservando le operazioni critiche. Verifica che questi controlli riducano davvero il carico e comunichino ai clienti un esito chiaro.

Se l'obiettivo non rientra nella data o nel budget, presenta al prodotto opzioni concrete: acquisire utenti per fasi, ridurre una funzione costosa o finanziare il collo di bottiglia misurato. Spiega impatto sui clienti e incertezza di ogni opzione.

**Da ricordare:** ipotesi di crescita → obiettivi di servizio → limiti misurati → piano con responsabili → rilascio provato. Il tech lead produce un piano di capacità che comprende persone, denaro e recupero.

Osservazione	Azione da valutare	Evidenza richiesta
Letture costose ripetute	Migliorare la query o memorizzare risultati adatti in cache	Meno lavoro nel database con aggiornamento accettabile.
Task in background competono con gli acquisti	Limitarne o separarne la capacità	Checkout sano durante il carico in background.
Quota di una dipendenza insufficiente	Concordare un aumento o controllare l'ammissione	Quota confermata e comportamento al limite verificato.
Capacità ancora insufficiente dopo interventi minori	Valutare scaling o un cambiamento architetturale maggiore	Beneficio misurato, piano di migrazione e costo.

1. Traduci la crescita in carico di lavoro

2. Concorda cosa deve mantenere una buona qualità

3. Misura il limite attuale prima di scegliere le modifiche

4. Trasforma le osservazioni in attività con responsabili

5. Simula la campagna e aumenta gradualmente il traffico

Domande correlate