System design interview: un solo framework, qualsiasi problema.

Il framework in cinque fasi (per un colloquio di 45 minuti)

1. Requisiti: 5 minuti. Separa i requisiti funzionali (“accorciare un URL, reindirizzare, alias personalizzati?”) da quelli non funzionali (scala, obiettivi di latenza, disponibilità o coerenza, durabilità). Chiedi i numeri: utenti, rapporto tra letture e scritture, dimensione dei dati. Poi dichiara ad alta voce il perimetro: “Progetto per 100 milioni di DAU, con un carico sbilanciato sulle letture 100:1 e redirect sotto i 100 ms, e lascio fuori gli analytics, a meno che non avanzi tempo.” Dichiarare il perimetro ad alta voce è la mossa che dà più segnale in tutto il colloquio.
2. Stime: 5 minuti. Calcoli a spanne di QPS, spazio di archiviazione, banda. Arrotonda alle potenze di dieci, dichiara le ipotesi, verifica la plausibilità (“500 milioni di nuovi URL al mese ≈ 200 scritture al secondo: poca cosa; le letture a 100:1 ≈ 20.000 al secondo: è questo che guida il design”). Il punto non è la precisione, ma mostrare che sono i numeri a guidare le tue scelte di architettura.
3. Design di alto livello: 10 minuti. Riquadri e frecce per il percorso ideale: client, load balancer, livello applicativo stateless, data store, cache, coda. Segui ad alta voce una richiesta dall'inizio alla fine. Resta sul classico: qui la novità è un rischio senza ricompensa.
4. Approfondimenti: 20 minuti. L'intervistatore sceglie un componente (“come fa esattamente la generazione degli ID a evitare le collisioni?”, “che cosa succede se un nodo della cache muore?”). È qui che i livelli si separano. Vai sul concreto: modello dei dati, scelta della chiave di partizionamento, modalità di guasto, che cosa fa squillare il telefono di chi è reperibile alle 3 di notte.
5. Chiusura: 5 minuti. I colli di bottiglia che affronteresti subito dopo, che cosa terresti monitorato, che cosa hai lasciato fuori di proposito. Chiudere con i limiti noti viene letto come seniority, non come debolezza.

Il lessico dei trade-off che segnala seniority

Gli intervistatori ascoltano se tiri in ballo questi assi di tua iniziativa:

I dieci problemi più comuni nelle system design interview, con il nodo di ciascuno

1. URL shortener. Il nodo: la generazione degli ID (contatore + base62 oppure hash + gestione delle collisioni) e la cache sul percorso di lettura. Un classico riscaldamento: aspettati domande di approfondimento su analytics e scadenza dei link.
2. Sistema di chat (WhatsApp/Slack). Il nodo: gestione delle connessioni (WebSocket, presenza), ordinamento dei messaggi per conversazione, garanzie e conferme di consegna, sincronizzazione offline.
3. News feed (Twitter/Instagram). Il nodo: la strategia di fan-out e il problema delle celebrità; il ranking come servizio separato; la paginazione con cursori, non con offset.
4. Rate limiter. Il nodo: la scelta dell'algoritmo (token bucket o sliding window), il conteggio distribuito (Redis + Lua), fail-open o fail-closed, e dove collocarlo (sul gateway o in ogni servizio).
5. Archiviazione di file (Dropbox/Drive). Il nodo: chunking e deduplicazione, protocollo di sincronizzazione e risoluzione dei conflitti, separazione tra metadati e blob.
6. Piattaforma video (YouTube). Il nodo: pipeline di caricamento (transcodifica con job asincroni), strategia di CDN, bitrate adattivo; i costi dello storage.
7. Abbinamento delle corse (Uber). Il nodo: indicizzazione geospaziale (geohash/quadtree), volume di scritture per gli aggiornamenti di posizione, il matching come servizio stateful, il surge come feed di prezzi.
8. Sistema di notifiche. Il nodo: astrazione multicanale (push/email/SMS), preferenze e limiti di frequenza per utente, idempotenza e retry con deduplicazione, code con priorità.
9. Cache distribuita. Il nodo: consistent hashing, policy di eviction, cache-aside o write-through, protezione dal thundering herd (request coalescing, TTL con jitter).
10. Sistema di metriche e monitoraggio. Il nodo: volume di scritture delle serie temporali, downsampling e livelli di retention, esplosione della cardinalità dei tag, valutazione degli alert come elaborazione in streaming.

Provane almeno tre dall'inizio alla fine, ad alta voce, su una lavagna o in un documento, al ritmo di 45 minuti. Raccontare un design e scriverlo sono due abilità diverse, e il colloquio valuta il racconto. Una simulazione con un assistente AI per colloqui di lavoro ti dà un feedback, trascrizione alla mano, sul punto esatto in cui la tua spiegazione ha perso il filo; ChadFlow può anche guardare la finestra del tuo diagramma durante un colloquio dal vivo e aiutarti quando arriva una domanda di approfondimento.

I cinque modi in cui i candidati falliscono questo colloquio

• Saltare i requisiti. Progettare benissimo il sistema sbagliato è l'errore più comune. Bastano trenta secondi per definire il perimetro ed evitarlo.
• Stime di facciata. Fare i conti e poi non usare mai i numeri. Se la tua stima dei QPS non cambia il design, era solo scena.
• Architettura a colpi di buzzword. Buttare lì Kafka/Cassandra/Kubernetes senza la giustificazione basata sulle proprietà descritta sopra.
• Fare un monologo. Il colloquio è una prova di collaborazione. Fermati a chiedere: “preferisci che approfondisca il livello di storage o che passi all'API?”
• Nessuna risposta sui guasti. Per ogni componente che disegni dovresti saper rispondere a “che cosa succede se questo muore?”. Prepara la risposta prima di disegnare il riquadro.