Colloquio di System Design: Come Strutturare la Tua Risposta

Perché I Buoni Ingegneri Falliscono i Colloqui di System Design

Hai costruito sistemi distribuiti. Hai fatto debug di interruzioni in produzione. Sai cos'è una CDN. Eppure, quando qualcuno dice "Progetta Twitter," la tua mente si svuota.

Il problema non è la conoscenza—è la struttura. Le domande di system design sono deliberatamente aperte. Senza un framework chiaro, salti da un componente all'altro, dimentichi di chiarire i requisiti e finisci il tempo prima di aver coperto le parti importanti.

Gli intervistatori non valutano il tuo diagramma finale. Guardano come pensi: raccogli requisiti, proponi un design, identifichi i colli di bottiglia e ragioni sui trade-off? È questo che il colloquio di system design testa davvero.

Il Framework in 5 Passi per Qualsiasi Colloquio di System Design

Passo 1: Chiarisci i Requisiti (3–5 minuti)

Prima di disegnare qualsiasi cosa, fai domande. Non è una tattica per prendere tempo—è la parte più importante.

Requisiti funzionali — cosa deve fare il sistema:

• Quali sono le azioni principali degli utenti? (post, lettura, ricerca, follow?)
• Quali casi d'uso sono fuori ambito?

Requisiti non funzionali — come deve comportarsi il sistema:

• Scala: quanti utenti attivi giornalieri? Più letture o più scritture?
• Obiettivi di latenza: cosa è accettabile per l'azione principale dell'utente?
• Disponibilità: qual è lo SLA di uptime? Possiamo tollerare brevi interruzioni durante i deploy?
• Coerenza: serve coerenza forte, o va bene quella eventuale?

Scrivi i numeri. "1M utenti giornalieri, rapporto letture/scritture 100:1, p99 < 200ms per le letture" — questo dà forma a ogni decisione architetturale che prendi.

Non saltare questo passo anche se il prompt sembra chiaro. Gli intervistatori lasciano ambiguità intenzionalmente per vedere se fai domande.

Passo 2: Stima la Scala (2–3 minuti)

I calcoli di back-of-the-envelope fondano il tuo design. Per un sistema con molte letture con 10M DAU:

• Supponi 50 letture/giorno per utente → 500M letture/giorno → ~6.000 letture/secondo
• Storage: se ogni record è 1KB e memorizzi 10M nuovi record/giorno → 10GB/giorno → 3,6TB/anno

Questi numeri ti dicono se ti serve un singolo database o lo sharding, se basta un singolo nodo di cache e quale dovrebbe essere la tua strategia CDN.

Passo 3: Design di Alto Livello (10–12 minuti)

Ora disegna. Inizia con il design più semplice che soddisfa i tuoi requisiti. Un buon design di alto livello per la maggior parte dei sistemi include:

• Client → API Gateway → Servizi applicativi
• Database — che tipo e perché (relazionale, NoSQL, time-series)?
• Cache — cosa stai mettendo in cache e perché?
• Elaborazione asincrona — dove si inserisce una message queue?
• CDN — per contenuto statico o letture distribuite geograficamente

Ad esempio, un URL shortener su larga scala:

1. Percorso di scrittura: Client → API → Server applicativo → DB (scrive mapping short:long) + Cache
2. Percorso di lettura: Client → CDN → Load balancer → Server app → Cache (Redis) → DB su cache miss
3. Generazione URL short: Usa un ID basato su contatore con codifica base-62 o un generatore di ID distribuito (Snowflake)

Dichiara le tue scelte ad alta voce: "Sto usando PostgreSQL qui perché i dati sono relazionali e ci serve coerenza forte per le scritture. Per le letture, metterò Redis davanti."

Passo 4: Deep-Dive (10–15 minuti)

Dopo l'alto livello, l'intervistatore di solito ti indirizza verso le aree che gli interessano di più. Argomenti di deep-dive comuni:

• Progettazione dello schema database — quali sono le tue tabelle, indici, strategia di sharding?
• Strategia di caching — cache-aside vs. write-through? TTL? Invalidazione della cache?
• Gestione degli hot spot — cosa succede quando i post di un utente famoso ricevono 10M di visite?
• Coerenza vs. disponibilità — dove stai facendo quel trade-off esplicitamente?
• Data fan-out — per i feed social, come propaghi le scritture ai follower?

Vai in profondità quando ti viene chiesto. L'intervistatore vuole vederti andare oltre "metti una cache davanti al database" verso "ecco la politica di eviction, ecco come gestisco le cache stampede, ecco il trade-off che sto facendo."

Passo 5: Trade-off e Alternative (5 minuti)

Chiudi riconoscendo ciò che hai deliberatamente omesso o semplificato. Questo separa i buoni candidati da quelli eccellenti.

"Ho scelto la coerenza eventuale qui per ottenere un throughput di scrittura migliore—ma se il business richiedesse che ogni lettura rifletta l'ultima scrittura, dovrei ripensarci con la replicazione sincrona, che aggiunge latenza."

Questo segnala maturità ingegneristica: comprendi che ogni decisione architetturale è un trade-off, non una risposta giusta.

Domande Comuni del Colloquio di System Design e Cosa Testano Davvero

Gli Errori Più Grandi nei Colloqui di System Design

Passare subito a codice o diagrammi. Inizia sempre con i requisiti, anche se il problema sembra ovvio.

Progettare il sistema perfetto. Non esiste un sistema perfetto. L'intervistatore vuole ragionamento sui trade-off, non un diagramma da libro di testo.

Rimanere in silenzio. Narra il tuo pensiero ad alta voce. Se stai considerando due approcci, dillo. "Sto scegliendo tra X e Y—X ci dà migliori prestazioni di scrittura ma Y è più facile da scalare per le letture. Dato il nostro rapporto di lettura 100:1, andrò con Y."

Ignorare la scala. Ogni decisione dovrebbe collegarsi ai tuoi numeri. "Questo funziona a 1K QPS, ma a 100K QPS avremmo bisogno di fare sharding—ecco come lo affronterei."

Esercitati Ora

Conoscere il framework e applicarlo dal vivo sotto la pressione dell'intervistatore sono due cose molto diverse.

Prova una sessione gratuita su Interview Sparring →