Le 30 domande e risposte più frequenti per i colloqui di progettazione dei sistemi (2026)
Luca Bennett
Prepararsi a un colloquio di progettazione di sistemi significa prevedere come gli intervistatori valuteranno il pensiero architettonico sotto pressione. Domande per l'intervista sulla progettazione del sistema rivelare profondità, compromessi, giudizio sulla scalabilità e comunicazione attraverso discussioni strutturate.
Una solida preparazione apre le porte a ruoli in piattaforme cloud, sistemi distribuiti e ingegneria dei dati, dimostrando competenza tecnica attraverso analisi concrete. I professionisti che lavorano sul campo sviluppano competenze pratiche, supportano i team, aiutano i manager a prendere decisioni e rispondono a domande e risposte comuni, che spaziano dai neolaureati ai senior, includendo prospettive avanzate, di base e tecniche a livello globale. Per saperne di più ...
👉 Download gratuito del PDF: Domande e risposte per colloqui di progettazione di sistemi
Domande e risposte sulle migliori interviste sulla progettazione di sistemi
1) Spiegare cos'è la progettazione di sistemi e perché è importante nell'ingegneria del software.
La progettazione del sistema è la processo di definizione dell'architettura, dei componenti, delle interfacce e dei dati per un sistema per soddisfare requisiti specifici in modo scalabile, affidabile e manutenibile. Collega obiettivi di alto livello (ciò che il sistema dovrebbe realizzare) con decisioni concrete su tecnologia, protocolli e modelli di architettura. Una solida progettazione di sistema garantisce che un'applicazione funzioni bene sotto carico, rimanga tollerante ai guasti e possa evolversi nel tempo senza riscritture complete.
Nei colloqui, questo dimostra la tua capacità di bilanciare richieste funzionali con vincoli non funzionali come scalabilità, latenza, coerenza e disponibilità. Tutte le principali aziende tecnologiche valutano le competenze di progettazione di sistemi di un candidato per valutare il suo giudizio ingegneristico nel mondo reale.
2) Come si distingue l'High-Level Design (HLD) dal Low-Level Design (LLD) nell'architettura di sistema?
L'High-Level Design (HLD) si concentra su panoramica architettonica e componenti principali senza addentrarsi nei dettagli di implementazione. Mostra come interagiscono i sistemi, ad esempio, web server, banca dati, nascondiglio, API Gatewaye sistemi di messaggistica.
Il Low-Level Design (LLD) approfondisce definizioni di classe, metodi, strutture dati e logica dettagliata all'interno di ogni componente. L'HLD riguarda i componenti che utilizzerai e come interagiranno; l'LLD riguarda come implementerai tali interazioni. Comprendere entrambi aiuta gli esaminatori a valutare la tua visione d'insieme e le tue capacità ingegneristiche dettagliate.
3) Quali sono i parametri chiave delle prestazioni da considerare quando si progetta un sistema e perché?
Le metriche delle prestazioni aiutano a quantificare quanto un sistema soddisfi le esigenze degli utenti e dell'azienda. Le metriche chiave sono:
- latenza: Tempo necessario per elaborare una singola richiesta. Una latenza inferiore significa risposte più rapide.
- Throughput: Quantità di lavoro elaborata in un periodo (ad esempio, richieste al secondo). Una maggiore produttività indica efficienza sotto carico.
- Disponibilità: Percentuale di tempo in cui un sistema è operativo. L'elevata disponibilità è fondamentale per i servizi globali.
Queste metriche aiutano i progettisti a bilanciare i compromessi. Ad esempio, la memorizzazione nella cache riduce la latenza ma complica la coerenza dei dati. Dimostrare familiarità con queste metriche dimostra che si ha a cuore la qualità del sistema nel mondo reale.
| Metrico | Definizione | Importanza |
|---|---|---|
| Latenza | Tempo per richiesta | Esperienza utente |
| Throughput | Richieste per unità di tempo | Scalabilità |
| Disponibilità | Tempo di attività vs tempo di inattività | L’affidabilità |
4) Descrivere il bilanciamento del carico e perché è fondamentale nei sistemi distribuiti.
Il bilanciamento del carico è il processo di distribuire le richieste in arrivo su più server o servizi per impedire che un singolo nodo diventi un collo di bottiglia. Garantisce che la capacità sia utilizzata in modo ottimale, migliora i tempi di risposta e aumenta l'affidabilità del sistema, instradando il traffico lontano dalle istanze non integre.
Esistono diversi tipi di bilanciatori di carico. A Livello 4 (L4) il bilanciatore lavora a livello di trasporto (IP/porta), mentre un Livello 7 (L7) Il bilanciatore opera a livello applicativo, comprendendo la semantica HTTP/S. Il bilanciamento del carico è fondamentale per la tolleranza agli errori, la scalabilità senza tempi di inattività e gli aggiornamenti continui nei sistemi di produzione. Rispondere bene a questa domanda dimostra di aver compreso i compromessi fondamentali dei sistemi distribuiti tra prestazioni, coerenza e costi.
5) Come progetteresti un servizio TinyURL? Descrivi i componenti principali e i passaggi.
La progettazione di un servizio TinyURL comprende sia requisiti funzionali (abbreviazione degli URL, reindirizzamento degli utenti) sia requisiti non funzionali (scalabilità, unicità, prestazioni).
Innanzitutto, le domande di chiarimento aiutano a definire i vincoli: volume previsto, politiche di scadenza, esigenze di analisi, ecc. I componenti principali sono:
- Livello API: Riceve ed elabora le richieste di abbreviazione/reindirizzamento.
- Database e memorizzazione nella cache: Memorizza le mappature URL originali ↔ abbreviate; la memorizzazione nella cache migliora le prestazioni di lettura.
- Generatore di ID brevi: Utilizza l'hashing o ID univoci codificati in base.
Per generare chiavi univoche in modo efficiente, puoi:
- Usa il codifica base-62 di un ID sequenziale (ad esempio, 1 → a, 2 → b, ecc.).
- Utilizzare funzione hash con risoluzione delle collisioni.
Dovresti anche considerare l'analisi, i limiti di velocità e la gestione degli URL più richiesti con livelli di caching o CDN per ridurre il carico. Descrivere questi compromessi dimostra la profondità sia dei modelli di progettazione che delle considerazioni sulla scalabilità.
6) Che cos'è la memorizzazione nella cache e in che modo migliora le prestazioni del sistema?
Memorizzazione nella cache dei negozi dati a cui si accede frequentemente o costosi da elaborare in un supporto di memorizzazione più veloce (memoria, cache distribuita) per ridurre il carico di elaborazione ripetuto e il carico del database. Migliora significativamente la latenza e la produttività, soddisfacendo rapidamente le richieste più frequenti.
La memorizzazione nella cache può avvenire a più livelli: memoria dell'applicazione, Redis/Ehcache, server edge CDN o archiviazione locale del browser. Sebbene la memorizzazione nella cache riduca i tempi di risposta, introduce problemi di obsolescenza e invalidazione, che è necessario affrontare in fase di progettazione. Ad esempio, è possibile utilizzare policy time-to-live (TTL) o strategie di invalidazione della cache quando i dati sottostanti cambiano. Risposte efficaci dimostrano di aver compreso entrambi gli aspetti. benefici e insidie della memorizzazione nella cache.
7) Spiegare il teorema CAP e le sue implicazioni sulla progettazione di sistemi distribuiti.
Il teorema CAP afferma che in un sistema distribuito è possibile scegliere al massimo due delle seguenti tre garanzie:
- Consistenza: Tutti i nodi vedono gli stessi dati contemporaneamente.
- Disponibilità: Ogni richiesta riceve una risposta (senza garanzia di correttezza).
- Tolleranza di partizione: Il sistema continua a funzionare nonostante i guasti della rete.
Nessun sistema distribuito pratico può raggiungere tutti e tre gli obiettivi simultaneamente in presenza di partizioni di rete. Ad esempio, durante una partizione, i sistemi devono scegliere tra fornire dati obsoleti (disponibilità) o rifiutare le richieste fino al ripristino della coerenza (coerenza). Comprendere il CAP dimostra che è possibile effettuare compromessi informati in base alle priorità operative, una competenza fondamentale nei colloqui di progettazione di sistemi.
8) Come progetteresti un servizio di messaggistica istantanea come WhatsApp in termini generali?
Per progettare un sistema di chat su larga scala, è necessario iniziare identificando i requisiti chiave: recapito dei messaggi in tempo reale, persistenza, ordinamento dei messaggi, supporto offline e scalabilità.
Ad alto livello:
- Clienti connettersi tramite web/mobile ai server gateway.
- Router di messaggi gestire i messaggi in arrivo e inviarli ai destinatari (tramite connessioni persistenti come WebSocket).
- Database memorizzare la cronologia dei messaggi, con un partizionamento appropriato per ampie basi di utenti.
I componenti aggiuntivi includono cache per le chat recenti, code per la consegna asincrona e servizi di notifica per gli utenti offline. Dovresti discutere come i messaggi vengono conservati, ordinati e recapitati a più dispositivi per utente e come gestire il failover e la tolleranza agli errori.
9) Cos'è lo sharding e come aiuta a scalare i database?
Lo sharding è una forma di ridimensionamento orizzontale dove un ampio set di dati viene suddiviso in partizioni più piccole e indipendenti, chiamate shard, ciascuna archiviata su un nodo di database diverso. Ciò migliora le prestazioni e la scalabilità distribuendo i dati e il carico delle query su più macchine anziché scalare una singola istanza.
I dati possono essere suddivisi in base all'ID cliente, all'area geografica o all'hashing. Sebbene lo sharding riduca il carico per nodo, introduce complessità nelle query cross-shard e nel ribilanciamento durante l'aggiunta o la rimozione di nodi. Gli intervistatori si aspettano che comprendiate questi compromessi e come l'hashing coerente o la gestione degli shard possano semplificare le operazioni.
10) Descrivi in che modo le API e i microservizi differiscono da un'architettura monolitica.
A Monolithic architecture Raggruppa tutti i componenti dell'applicazione in un'unica unità distribuibile. Questo può semplificare inizialmente lo sviluppo, ma diventa difficile da scalare, mantenere e aggiornare nel tempo.
Microservices rompere il sistema in piccoli servizi distribuibili in modo indipendente, ognuno responsabile di una specifica funzionalità aziendale. Le API (Application Programming Interface) consentono la comunicazione tra questi servizi.
| Aspetto | Monolitico | Microservices |
|---|---|---|
| Distribuzione | Unità singola | Servizi indipendenti |
| Scalabilità | Limitato | Scalabilità per servizio |
| Isolamento dei problemi | povero | Forte |
| Complessità | Inizialmente più semplice | Operazioni più complesse |
I microservizi migliorano la scalabilità e la flessibilità di distribuzione, ma richiedono strumenti operativi avanzati (individuazione dei servizi, tracciamento e tolleranza agli errori). Discutere di questo aspetto dimostra che è possibile ragionare sull'evoluzione dell'architettura e sui compromessi tra semplicità e flessibilità.
11) Come funziona una Content Delivery Network (CDN) e quali sono i suoi vantaggi?
A Rete di distribuzione dei contenuti (CDN) è una rete distribuita di server proxy strategicamente posizionati in varie regioni geografiche. Il suo obiettivo principale è quello di fornire contenuti agli utenti con una latenza minima servendolo dal server più vicino (noto come nodo edge).
Quando un utente richiede una risorsa web (ad esempio, un'immagine, un video o un file statico), la CDN memorizza il contenuto nella cache e lo fornisce direttamente da un server periferico. Se il contenuto non è presente nella cache, lo recupera dal server di origine e lo memorizza per le richieste successive.
Vantaggi dei CDN:
| Fattore | Vantaggio |
|---|---|
| Latenza | Riduce i tempi di risposta offrendo contenuti più vicini agli utenti |
| Larghezza di banda | Scarica l'utilizzo della larghezza di banda dai server di origine |
| L’affidabilità | Fornisce tolleranza ai guasti con nodi distribuiti |
| Scalabilità | Gestisce in modo efficiente volumi di traffico elevati |
I CDN sono vitali per i sistemi globali come Netflix, YouTubeo piattaforme di e-commerce, garantendo elevate prestazioni e disponibilità.
12) Che cosa si intende per limitazione della velocità e perché è essenziale nella progettazione delle API?
Limitazione della velocità limita il numero di richieste che un client può effettuare a un'API entro un periodo di tempo specificato. È fondamentale per prevenire gli abusi, mantenimento del fair usee protezione dei servizi backend da attacchi di sovraccarico o di negazione del servizio (DoS).
Gli algoritmi più comuni per la limitazione della velocità includono:
- Contatore finestra fisso — Semplice, ma potrebbe causare picchi ai bordi delle finestre.
- Finestra scorrevole / finestra scorrevole — Consente una gestione più fluida delle richieste.
- Secchio di token / Secchio che perde — Consente raffiche entro certi limiti e mantiene un flusso di richieste costante.
Ad esempio, GitHub limita le chiamate API a 5000 all'ora per utente. L'implementazione di limiti di frequenza garantisce la stabilità del sistema e migliora la qualità complessiva del servizio.
13) Come si garantisce la coerenza dei dati nei sistemi distribuiti?
Mantenere la coerenza nei sistemi distribuiti è una sfida a causa della replicazione e della latenza di rete. Esistono diverse strategie, a seconda del compromesso richiesto tra coerenza e disponibilità:
| Tipo di coerenza | Descrizione | Usa caso |
|---|---|---|
| Forte coerenza | Tutti i clienti vedono gli stessi dati all'istante | Sistemi bancari |
| Eventuale coerenza | Gli aggiornamenti si propagano in modo asincrono; sono consentite differenze temporanee | Feed di social media |
| Coerenza causale | Mantiene l'ordine causa-effetto | App collaborative |
Tecniche come registri write-ahead, orologi vettoriali, algoritmi di consenso (Raft, Paxos)e commit in due fasi (2PC) aiuta a mantenere la sincronizzazione. Gli intervistatori si aspettano che tu spieghi when per allentare la coerenza per ottenere guadagni in termini di prestazioni e scalabilità.
14) Spiega la differenza tra ridimensionamento orizzontale e verticale.
Il ridimensionamento si riferisce all'aumento della capacità di un sistema di gestire carichi maggiori. Esistono due tipi principali:
| Tipo di ridimensionamento | Metodo | Vantaggi | Svantaggi |
|---|---|---|---|
| Scalabilità verticale (Scale-Up) | Aggiungere più risorse (CPU, RAM) a una singola macchina | Più semplice da implementare | Limiti hardware, singolo punto di errore |
| Scalabilità orizzontale (Scale-Out) | Aggiungere più macchine per distribuire il carico | Alta disponibilità, conveniente | Complesso da gestire e coordinare |
Ad esempio, scalare un server web da 2 a 8 CPU è un ridimensionamento verticale, mentre aggiungere più server dietro un bilanciatore di carico è un ridimensionamento orizzontale. I moderni sistemi distribuiti come Kubernetes favoriscono ridimensionamento orizzontale per elasticità.
15) Cosa sono le code di messaggi e perché vengono utilizzate nelle architetture distribuite?
A coda di messaggi disaccoppia produttori e consumatori memorizzando temporaneamente i messaggi fino a quando non vengono elaborati. Ciò consente comunicazione asincrona, migliorando la resilienza e la scalabilità nei sistemi distribuiti.
I broker di messaggi più diffusi includono RabbitMQ, Kafka, Amazon SQSe Google Pub/Sub.
Vantaggi:
- Smussa i picchi di traffico
- Servizi di disaccoppiamento
- Abilita meccanismi di ripetizione e persistenza
- Migliora la tolleranza ai guasti
Esempio: In una piattaforma di e-commerce, un servizio di ordini può pubblicare un messaggio ("Ordine effettuato") che i servizi di inventario e fatturazione utilizzano in modo indipendente, evitando dipendenze dirette.
16) Come progetteresti un sistema di archiviazione file scalabile come Google Drive or Dropbox?
Per progettare un sistema di archiviazione file basato sul cloud, è necessario suddividerlo in componenti chiave:
- Servizio frontend: Gestisce il caricamento/scaricamento dei file tramite API REST.
- Servizio metadati: Memorizza la proprietà dei file, le autorizzazioni di accesso e la cronologia delle versioni.
- Servizio di deposito: Gestisce blocchi di file in storage distribuito (ad esempio, S3, HDFS).
- chunking: I file vengono suddivisi in blocchi più piccoli (ad esempio, 4 MB) per una memorizzazione e una trasmissione efficienti.
Le sfide includono garantire deduplicazione dei dati, coerenzae sincronizzazione delle modifiche su tutti i dispositivi. L'implementazione della sincronizzazione a livello di blocco e dell'hashing dei contenuti garantisce efficienza e integrità della larghezza di banda.
17) Quali sono i fattori chiave da considerare quando si progetta uno schema di database scalabile?
Uno schema scalabile bilancia prestazioni, flessibilità e manutenibilità. Tra le considerazioni importanti figurano:
- Partizionamento dei dati (sharding) per gestire la crescita.
- Normalizzazione vs. Denormalizzazione: Normalizzare per l'integrità; denormalizzare per prestazioni di lettura intensive.
- Strategia di indicizzazione per ricerche rapide.
- Memorizzazione nella cache e replicazione per gestire un traffico intenso.
Esempio: In un'applicazione di social media, i dati degli utenti e i post possono essere archiviati separatamente per ridurre l'accoppiamento e migliorare le prestazioni delle query. Le decisioni di progettazione dello schema dovrebbero essere in linea con modelli di accesso e frequenza delle query.
18) Quali sono i vantaggi e gli svantaggi dell'utilizzo dell'architettura dei microservizi?
I microservizi sono diventati la spina dorsale delle moderne applicazioni cloud, ma comportano dei compromessi.
| Vantaggi | Svantaggi |
|---|---|
| Distribuzione e scalabilità indipendenti | Maggiore complessità operativa |
| Isolamento dei guasti e resilienza | Il debug distribuito è più difficile |
| Adozione più semplice della tecnologia | Richiede una forte cultura DevOps |
| Migliore manutenibilità del codice | Maggiore latenza dovuta ai salti di rete |
I microservizi sono ideali per sistemi di grandi dimensioni e in evoluzione, ma richiedono un monitoraggio affidabile, gateway API e strategie di comunicazione tra servizi.
19) Come gestiresti la replicazione del database in un sistema su larga scala?
Replica della banca dati consiste nel copiare i dati da un database primario a una o più repliche per migliorare la disponibilità e le prestazioni di lettura. Esistono due tipi principali:
| Tipo di replica | Descrizione | Usa caso |
|---|---|---|
| Synccronico | Le modifiche vengono scritte immediatamente sulle repliche | Consistenza forte |
| asincrono | Il primario conferma la scrittura prima dell'aggiornamento delle repliche | Migliori prestazioni |
La replicazione migliora tolleranza d'erroreche consentono distribuzione geograficae supporta scala di lettura (leggi repliche). Tuttavia, introduce sfide come il ritardo di replicazione e la risoluzione dei conflitti. Strumenti come MySQL Replicazione di gruppo, MongoDB Set di replichee PostgreSQL replicazione in streaming sono soluzioni standard.
20) Che cos'è l'architettura basata sugli eventi e in quali ambiti è più utile?
L'architettura basata sugli eventi (EDA) è un paradigma di progettazione in cui i componenti comunicano tramite eventi — messaggi che segnalano cambiamenti di stato o azioni. Invece di richieste dirette, i servizi pubblicano e si iscrivono agli eventi in modo asincrono.
Questo design è ideale per sistemi debolmente accoppiati, come piattaforme IoT, e-commerce e sistemi di analisi in tempo reale.
Vantaggi:
- Alta scalabilità
- Componenti disaccoppiati
- Reattività in tempo reale
Esempio: Nell'architettura di Uber, quando viene prenotata una corsa, un evento attiva simultaneamente gli aggiornamenti nei sistemi di prezzi, abbinamento dei conducenti e notifiche, il tutto senza stretti collegamenti.
21) Che cosa è l'idempotenza nella progettazione dei sistemi e perché è importante?
Idempotenza significa che eseguire la stessa operazione più volte ha il stesso effetto di eseguirlo una voltaGarantisce l'affidabilità nei sistemi distribuiti in cui le richieste possono essere ripetute a causa di guasti o ritardi di rete.
Per esempio:
- GET e DELETE le richieste sono naturalmente idempotenti (ripetendole non si modifica lo stato).
- POST le richieste (come la creazione di una transazione) non sono idempotenti a meno che non siano specificamente progettate per esserlo.
Per implementare l'idempotenza:
- Usa il ID di richiesta univoci per tenere traccia degli invii duplicati.
- Mantenere un log delle transazioni per ignorare le operazioni ripetute.
Questo principio è fondamentale in gateway di pagamento, Elaborazione dell'ordinee sistemi di posta elettronica dove azioni duplicate possono causare gravi incongruenze.
22) Spiega il concetto di coerenza eventuale con un esempio.
Consistenza finale è un modello nei database distribuiti in cui gli aggiornamenti non sono immediatamente visibili a tutti i nodi, ma il sistema converge verso uno stato coerente nel tempo.
Esempio:
In Amazon'S DynamoDBQuando un elemento viene aggiornato in una regione, le repliche in altre regioni potrebbero temporaneamente contenere dati obsoleti. Tuttavia, alla fine verranno sincronizzate tramite replica in background.
Questo modello è utile nei sistemi che danno priorità disponibilità ancora rigorosa coerenza, Quali:
- Cronologie dei social media
- Sistemi di memorizzazione nella cache
- Record DNS
Il compromesso chiave risiede tra tolleranza alla stantiezza e velocità di risposta.
23) Come progetteresti un sistema di notifica che supporti più canali (e-mail, SMS, push)?
La progettazione di un sistema di notifica scalabile richiede modularità e flessibilità.
Architecnologia:
- API di notifica – Riceve le richieste di notifica dalle applicazioni.
- Bus di coda/messaggi – Memorizza e distribuisce eventi (Kafka, SQS).
- Servizi per i lavoratori – Processori specifici per canale (e-mail, SMS, push).
- Fornitori di consegna – Integrazione con API esterne come Twilio o Firebase.
- DB delle preferenze utente – Memorizza le impostazioni di adesione/esclusione e le preferenze di frequenza.
Considerazioni chiave:
- Ripeti le consegne non riuscite con strategie di backoff.
- Utilizzare modelli per coerenza.
- Supportare la definizione delle priorità (messaggi urgenti vs. messaggi a bassa priorità).
Questa progettazione modulare garantisce affidabilità ed estensibilità man mano che emergono nuovi canali di notifica.
24) Che cos'è l'indicizzazione del database e in che modo influisce sulle prestazioni?
A indice del database è una struttura dati (comunemente un albero B o una tabella hash) che migliora la velocità delle query riducendo il numero di record analizzati dal database.
Ad esempio, l'indicizzazione della colonna e-mail in una tabella utente consente al motore del database di trovare rapidamente gli utenti tramite e-mail senza dover analizzare l'intera tabella.
| Aspetto | Con indice | Senza indice |
|---|---|---|
| Velocità di richiesta | Ricerche veloci | Scansioni sequenziali lente |
| velocità di scrittura | Più lento (necessari aggiornamenti dell'indice) | Scritture più veloci |
| Archiviazione | Più spazio su disco | Less conservazione |
Gli indici migliorano le prestazioni di lettura ma devono essere usati con giudizio, poiché possono rallentare scrittura pesante sistemi a causa dei costi di manutenzione.
25) Come garantiresti la tolleranza ai guasti in un sistema distribuito su larga scala?
Tolleranza ai guasti significa che un sistema continua a funzionare anche quando i componenti si guastano. Ciò è possibile grazie a ridondanza, monitoraggio e ripristino automatico.
Le strategie includono:
- Replica: Dati o servizi duplicati tra regioni.
- Meccanismi di failover: Reindirizza automaticamente le richieste ai nodi sani.
- Controlli di integrità e bilanciatori del carico: Rileva e isola le istanze difettose.
- Interruttori: Prevenire guasti a cascata tra servizi dipendenti.
Esempio: Netflix"Chaos Monkey" di arresta intenzionalmente le istanze in produzione per testarne la resilienza, un'applicazione avanzata dei principi di tolleranza agli errori.
26) Qual è la differenza tra comunicazione sincrona e asincrona nei sistemi distribuiti?
| caratteristica | SyncComunicazione onoraria | Comunicazione asincrona |
|---|---|---|
| Dipendenza | Il mittente attende la risposta | Il mittente procede in modo indipendente |
| Esempi | Chiamate API REST HTTP | Code di messaggi, Kafka |
| Latenza | Più alto (bloccante) | Minore latenza percepita |
| L’affidabilità | Inferiore in caso di guasti | Più alto (i messaggi possono persistere) |
SyncI sistemi sincroni sono più semplici ma strettamente accoppiati, mentre i sistemi asincroni migliorano la scalabilità e l'isolamento dei guasti.
Ad esempio, l'elaborazione degli ordini in un sistema di e-commerce può essere asincrona, ma la conferma del pagamento dovrebbe rimanere sincrona per garantire un feedback immediato da parte dell'utente.
27) Come progetteresti un limitatore di velocità per un sistema API distribuito?
Un limitatore di velocità distribuito garantisce un utilizzo equo dell'API su più server.
Approcci:
- Algoritmo token bucket – Ogni utente riceve dei token che si rigenerano nel tempo.
- Algoritmo del secchio che perde – Le richieste vengono elaborate a un ritmo costante.
- Contatore centralizzato (ad esempio, Redis) – Mantiene il conteggio delle richieste per utente.
Esempio di implementazione:
- Utilizzare contatori atomici Redis con TTL.
- Tieni traccia dei timestamp delle richieste per chiave utente.
- Rifiuta le richieste che superano le soglie.
La limitazione della velocità impedisce abuso, Attacchi DoSe picchi di costo inaspettati, garantendo una qualità del servizio costante per tutti i clienti.
28) Che cos'è un algoritmo di consenso distribuito e perché è necessario?
Gli algoritmi di consenso distribuito garantiscono che più nodi in un sistema concordare su un singolo valore di dati, anche quando si verificano guasti.
Algoritmi comuni:
- Paxos
- Raft
- Zab (utilizzato in ZooKeeper)
Sono essenziali per il mantenimento elezione del leader, replicazione dello statoe consistenza dei dati nei database distribuiti e nei gestori di cluster come Kubernetes.
Esempio: Raft garantisce che tutti i nodi concordino sulle voci di registro prima di applicarle alle macchine a stati, garantendo l'affidabilità anche in caso di crash dei nodi.
29) Come progetteresti un sistema di registrazione e monitoraggio per i microservizi?
Il monitoraggio dei sistemi distribuiti richiede un'osservabilità centralizzata per rilevare e risolvere i problemi.
Componenti principali:
- Registrazione: Raccogli i log da tutti i servizi utilizzando strumenti come Fluentd or Logstash.
- Metrica: Utilizzare Prometheus o Datadog per monitorare gli indicatori di prestazione (CPU, memoria, latenza delle richieste).
- Tracciamento: Implementare il tracciamento distribuito (Jaeger, Zipkin) per tracciare i percorsi delle richieste tra i servizi.
- Avviso: Imposta soglie per attivare gli avvisi in PagerDuty o Slack.
migliori Pratica:
Usa il ID di correlazione per tracciare una singola richiesta utente su più microservizi, fondamentale per risolvere i problemi di produzione.
30) Quali sono le principali considerazioni progettuali per la realizzazione di un sistema ad alta disponibilità (HA)?
A Alta disponibilità (HA) il sistema riduce al minimo i tempi di inattività e garantisce un servizio continuo.
Fattori chiave di progettazione:
- Ridondanza: Utilizzare più server per componente.
- Eliminare i singoli punti di errore (SPOF).
- Failover automatico: Reindirizzare il traffico durante le interruzioni.
- Replica dei dati: Garantire la durabilità dei dati in tutte le zone.
- Monitoraggio della salute: Rileva e sostituisci automaticamente i nodi non funzionanti.
- Ripristino di emergenza (DR): Implementare backup e georeplicazione.
Esempio: AWS distribuisce i servizi nelle zone di disponibilità (AZ) e utilizza Elastic Load Balancer per il failover automatico, garantendo SLA con uptime del 99.99%.
🔍 Le migliori domande per i colloqui di progettazione di sistemi con scenari reali e risposte strategiche
1) Come si affronta la progettazione di un sistema distribuito su larga scala partendo da zero?
Requisiti richiesti al candidato: L'intervistatore vuole capire il tuo modo di pensare strutturato, la tua capacità di chiarire i requisiti e il modo in cui scomponi problemi complessi in componenti gestibili.
Esempio di risposta: "Inizio chiarendo i requisiti funzionali e non funzionali, come scalabilità, disponibilità e latenza. Poi delineo un'architettura di alto livello, identifico i componenti principali, definisco il flusso di dati e seleziono le tecnologie appropriate. Dopodiché, prendo in considerazione colli di bottiglia, scenari di errore e compromessi prima di perfezionare il progetto."
2) Puoi spiegare la differenza tra ridimensionamento orizzontale e verticale e quando dovresti utilizzarli?
Requisiti richiesti al candidato: L'intervistatore metterà alla prova le tue conoscenze di base in materia di scalabilità e la tua capacità di applicare la strategia corretta nei sistemi del mondo reale.
Esempio di risposta: "Il ridimensionamento verticale comporta l'aggiunta di più risorse a una singola macchina, mentre il ridimensionamento orizzontale aggiunge più macchine per gestire il carico. Il ridimensionamento verticale è più semplice ma limitato, mentre il ridimensionamento orizzontale è più complesso ma offre una migliore tolleranza agli errori e una scalabilità a lungo termine."
3) Come si garantisce un'elevata disponibilità nella progettazione di un sistema?
Requisiti richiesti al candidato: L'intervistatore vuole valutare la tua comprensione della ridondanza, dei meccanismi di failover e della resilienza del sistema.
Esempio di risposta: "Nel mio ruolo precedente, ho garantito un'elevata disponibilità utilizzando bilanciatori di carico, distribuendo servizi su più zone di disponibilità, implementando controlli di integrità e progettando servizi stateless ove possibile. Queste strategie hanno ridotto i singoli punti di errore."
4) Descrivi un momento in cui hai dovuto trovare un compromesso tra coerenza e disponibilità.
Requisiti richiesti al candidato: L'intervistatore valuterà la tua comprensione del teorema CAP e la tua capacità di prendere decisioni in presenza di vincoli.
Esempio di risposta: "In una posizione precedente, ho lavorato su un sistema in cui la bassa latenza era fondamentale. Abbiamo scelto la coerenza finale anziché la coerenza forte per mantenere la disponibilità durante le partizioni di rete, il che era accettabile per il caso d'uso aziendale."
5) Come si decide quale database utilizzare per un dato sistema?
Requisiti richiesti al candidato: L'intervistatore vuole vedere come allinei le scelte di archiviazione dei dati con i requisiti di sistema.
Esempio di risposta: "Valuto i modelli di accesso ai dati, i requisiti di coerenza, le esigenze di scalabilità e la complessità delle query. I database relazionali funzionano bene per dati strutturati e transazioni, mentre i database NoSQL sono più adatti per un throughput elevato e schemi flessibili."
6) Come progetteresti un sistema per gestire picchi di traffico improvvisi?
Requisiti richiesti al candidato: L'intervistatore sta testando la tua capacità di progettare tenendo conto della scalabilità e del carico imprevedibile.
Esempio di risposta: "Utilizzavo gruppi di auto-scaling, bilanciatori di carico e livelli di caching come gli archivi in-memory. Nel mio ultimo ruolo, queste tecniche permettevano al sistema di assorbire picchi di traffico senza influire sulle prestazioni."
7) Quale ruolo gioca la memorizzazione nella cache nella progettazione del sistema e dove la implementeresti?
Requisiti richiesti al candidato: L'intervistatore vuole capire come ottimizzare le prestazioni e ridurre il carico sui servizi principali.
Esempio di risposta: "La memorizzazione nella cache migliora i tempi di risposta e riduce il carico del database. Può essere implementata a più livelli, tra cui lato client, CDN, a livello di applicazione e di query del database, a seconda del caso d'uso."
8) Come gestisci il partizionamento e lo sharding dei dati?
Requisiti richiesti al candidato: L'intervistatore sta valutando la tua capacità di progettare sistemi che scalano i dati orizzontalmente.
Esempio di risposta: "Scelgo una chiave di sharding che distribuisca uniformemente i dati e riduca al minimo le query tra shard. Pianifico anche il re-sharding e monitoro la distribuzione dei dati per evitare hotspot man mano che il sistema cresce."
9) Descrivere una situazione in cui il monitoraggio del sistema ha influenzato una decisione di progettazione.
Requisiti richiesti al candidato: L'intervistatore vuole vedere come utilizzi l'osservabilità per migliorare l'affidabilità e le prestazioni del sistema.
Esempio di risposta: "Monitorare parametri come latenza e tassi di errore ha evidenziato un collo di bottiglia in un servizio API. Sulla base di questa analisi, ho riprogettato il servizio in modo che fosse asincrono, migliorando significativamente la produttività."
10) Come si comunicano i progetti di sistemi complessi alle parti interessate non tecniche?
Requisiti richiesti al candidato: L'intervistatore valuterà le tue capacità comunicative e la tua capacità di allineare le decisioni tecniche con gli obiettivi aziendali.
Esempio di risposta: "Mi concentro su concetti di alto livello, utilizzo diagrammi e metto in relazione i componenti tecnici con i risultati aziendali. Questo approccio aiuta gli stakeholder a comprendere il valore e l'impatto del progetto senza perdersi nei dettagli tecnici."
