Domande di Colloquio sui Microservizi

Hai letto i nomi dei pattern, sai recitare a memoria cosa fa un circuit breaker, eppure non riesci a capire cosa ascolta un panel di selezionatori. Questa sezione elenca le quattro aree valutate dai selezionatori, nell'ordine in cui di solito le esplorano. Ognuna è una domanda di giudizio travestita da domanda di vocabolario.

• Decomposizione. Dove tagli, e perché lì? I selezionatori vogliono un confine tracciato lungo la capacità di business o la proprietà dei dati, non lungo i livelli tecnici.
• Comunicazione. Richiesta/risposta sincrona o eventi asincroni, e cosa si rompe in ciascun caso. La risposta desiderata è un compromesso, non una preferenza.
• Dati. Un database per servizio significa niente join tra servizi e nessuna transazione distribuita. Come mantieni comunque il sistema corretto?
• Operazioni. Deployment, versioning, tracing, e cosa succede alle tre di notte quando un servizio è lento anziché fermo.

Nota che nessuno di questi riguarda un framework. Un candidato che spiega perché ha separato checkout da inventory batte sempre chi elenca semplicemente le annotazioni.

Queste sono le domande che aprono la maggior parte dei colloqui sui microservizi, con ciò che il selezionatore verifica sotto ciascuna.

• Come suddivideresti questo monolite in servizi? Verifica se tagli lungo le capacità di business e la proprietà dei dati, oppure lungo i livelli controller, service e repository. La seconda risposta produce un monolite distribuito.
• Come comunicano due servizi tra loro? Verifica se sai nominare il costo di ogni scelta: le chiamate sincrone danno un modello mentale semplice ma accoppiano la disponibilità, gli eventi asincroni disaccoppiano la disponibilità e introducono la eventual consistency che devi spiegare a un product owner.
• Cos'è un monolite distribuito e come lo eviti? Verifica se sai che servizi che devono essere distribuiti insieme non sono davvero separati.
• Quanto dovrebbe essere grande un servizio? Verifica che tu resista a dare un numero. La dimensione segue il confine e il team che ne è proprietario.
• Serve un API gateway, e cosa fa? Verifica se sai separare routing, autenticazione e rate limiting dalla logica di business.
• Come si trovano i servizi tra loro? Verifica la familiarità di base con il service discovery e perché gli host hardcoded falliscono in un ambiente scalato.

Dì il compromesso ad alta voce in ogni risposta. Un panel non può assegnare punti per un confronto fatto silenziosamente nella tua testa.

È qui che i colloqui si vincono o si perdono, perché queste domande non hanno una risposta netta e i candidati ricorrono a una risposta imparata a memoria.

• Come mantieni i dati coerenti tra i servizi? Nomina prima il vincolo: non esiste una transazione tra servizi. Poi descrivi una saga, coreografata tramite eventi oppure orchestrata da un coordinatore, e dì chiaramente che il sistema è eventually consistent e cosa vede l'utente durante l'intervallo.
• Cosa succede quando un servizio a valle è lento? Timeout, retry con backoff, e un circuit breaker così che una dipendenza lenta non esaurisca il tuo thread pool. Essere lento è peggio che essere fermo, e dirlo segnala esperienza di produzione.
• Come rendi sicuro un retry? Idempotency. Una chiave di idempotenza sul percorso di scrittura, così un pagamento ripetuto viene addebitato una sola volta.
• Come gestisci un guasto parziale in un flusso multi-passaggio? Azioni compensative, non rollback. Spiega come appare un rimborso o il rilascio di una prenotazione.
• Come fai il debug di una richiesta che ha toccato sei servizi? Distributed tracing con un correlation ID propagato a ogni hop, più log strutturati e metriche.

Un backend engineer in colloquio per un ruolo platform L5 presso un fornitore cloud pubblico ha ricevuto la domanda sulla saga e ha risposto in un colpo solo, con vocabolario da pattern, senza mai menzionare cosa avrebbe visto il cliente. La domanda di follow-up, cosa mostra la pagina dell'ordine durante la finestra incoerente, è quella che decide davvero il colloquio. Prepara la seconda risposta, non solo la prima.

Altre raccolte di domande per ruolo e argomento sono disponibili sotto domande di colloquio per ruolo.

Leggere questa lista genera un senso di riconoscimento, e quel senso svanisce non appena uno sconosciuto pone la domanda e aspetta. Il divario tra conoscere un pattern e spiegarlo sotto una lieve pressione è l'intera difficoltà di un colloquio di system design, e si colma solo parlando.

Scegli un flusso che conosci bene, un ordine o una registrazione, e narra ad alta voce l'intera decomposizione: il confine, la scelta di comunicazione, la storia della coerenza, la storia del guasto. Fallo finché non smetti di ricominciare le frasi. Puoi provare questi prompt contro un intervistatore AI che fa domande di follow-up e ti lascia rispondere a voce nella modalità colloquio simulato, molto più vicina alla situazione reale che rileggere appunti.

Aaron Cao, fondatore di SubcueAI, ha costruito la modalità di esercizio attorno a quel divario, non attorno alla distribuzione di contenuti. Le liste di domande sono liberamente disponibili ovunque; ciò che manca ai candidati sono le ripetizioni di pronunciare la risposta mentre qualcuno aspetta. Durante un colloquio reale l'app desktop e il Side Panel dell'estensione del browser possono mostrare prompt strutturati mentre l'intervistatore parla, anche se una spiegazione provata batte sempre una che stai leggendo per la prima volta. Cosa fa e cosa non fa l'assistente è descritto nella panoramica del prodotto.