Domande Architettura — Cheat Sheet

Tag: architettura, design, system design, colloquio

Livello: intermedio

TL;DR: Raccolta di domande e risposte frequenti sui concetti di architettura software e system design per affrontare colloqui tecnici.

Concetti chiave

Conoscenza dei design pattern fondamentali (Creazionali, Strutturali, Comportamentali).

Comprensione delle differenze pratiche tra architetture a microservizi e monoliti.

Principi SOLID e la loro applicazione pratica nel codice.

Valutazione della scalabilità verticale rispetto a quella orizzontale.

Gestione della coerenza dei dati nei sistemi distribuiti tramite Teorema CAP o BASE.

Meccanismi di caching e relative strategie applicative (Write-through, Write-behind).

Code di messaggi e pattern di asincronicità (es. RabbitMQ, Kafka).

Domande tipiche e risposte pronte

Q: Quali sono i vantaggi e gli svantaggi di un'architettura a microservizi rispetto a un monolite?

R: I microservizi offrono scalabilità indipendente e deploy veloci, ma aumentano la complessità di rete. I monoliti sono semplici da sviluppare ma difficili da scalare.

Q: Spiegami il Teorema CAP.

R: In un sistema distribuito non puoi garantire contemporaneamente Coerenza, Disponibilità e Tolleranza alle partizioni. In presenza di partizioni, devo scegliere tra Coerenza e Disponibilità.

Q: Come gestiresti la scalabilità di un'applicazione che subisce un picco di traffico?

R: Aggiungerei un layer di caching aggressivo e scalerei orizzontalmente i server dietro un load balancer. Per il DB, valuterei read replicas o sharding.

Q: Cosa sono i principi SOLID e perché sono importanti?

R: Sono cinque principi (Single Responsibility, Open/Closed, Liskov, Interface, Dependency) che guidano il design object-oriented. Rendo così il codice manutenibile e testabile.

Q: Differenza tra database relazionali (SQL) e non relazionali (NoSQL)?

R: Gli SQL garantiscono transazioni ACID ideali per dati strutturati. I NoSQL offrono flessibilità e scalano orizzontalmente meglio per grandi moli di dati destrutturati.

Insidie e errori comuni

Proporre architetture complesse quando un monolite ben strutturato sarebbe più che sufficiente (overengineering).

Ignorare la latenza di rete nella comunicazione dei sistemi distribuiti.

Dimenticare di gestire scenari di guasto o i timeout.

Sottovalutare l'impatto e la complessità di una migrazione di dati in produzione.

Snippet e comandi

{
  "pattern": "CQRS",
  "description": "Command Query Responsibility Segregation separates read and update operations for a data store."
}

Da ripassare

[ ] Pattern di saga per transazioni distribuite.

[ ] API Gateway vs Service Mesh.

Modifica direttamente o con Gemini Fai clic in un punto qualsiasi per digitare e modificare direttamente oppure seleziona il testo per chiedere a Gemini di apportare modifiche.

Il documento è pronto per l'uso in Jarvis Interviews. Fammi sapere se hai bisogno di generare altre cheat sheet o se vuoi iterare su questo file.