Con il tempo ho imparato che prendere la decisione giusta non significa solo avere competenze tecniche. Bisogna saper valutare i compromessi, pensare agli effetti a lungo termine e collaborare efficacemente con gli altri.
In questo articolo voglio condividere come affronto il design architetturale di un sistema software e come prendo decisioni difficili.
Spoiler: non esiste quasi mai una risposta perfetta, ma solo la migliore per la situazione specifica.
L’architettura ci deve aiutare a comprendere il sistema
Prima ancora di buttarmi su diagrammi e whiteboard, mi costringo a capire davvero bene il problema.
Un problema ben definito porta a decisioni architetturali migliori.
Il mio approccio è semplice:
- Chiedere “Perché?”
Quando qualcuno dice “Serve passare a microservizi”, non mi limito ad annuire. Continuo a chiedere perché finché non emerge la vera motivazione: scalabilità, velocità di rilascio, organizzazione dei team… - Definire i vincoli
Performance, budget, competenze del team, requisiti di compliance: sono tutti fattori che plasmano l’architettura. - Parlare con gli stakeholder
Prodotto, business, operations: ognuno può rivelare esigenze nascoste, come vincoli legali, costi o problemi ricorrenti. - Chiarire i casi d’uso principali
Non progetto per i casi limite al giorno uno: mi concentro su ciò che il sistema deve fare eccezionalmente bene. - Scriverlo in una pagina
Se non riesco a riassumere problema e vincoli in una pagina, significa che non ho ancora chiara la situazione.
Alcune decisioni difficili (e come le affronto)
1️⃣ Semplicità o flessibilità?
Esempio: il servizio di pagamento di un e-commerce deve notificare spedizione e magazzino dopo una conferma di pagamento.
- Opzione A: REST API sincrone – facili da capire, ma fortemente accoppiate.
- Opzione B: Architettura event-driven (Kafka) – disaccoppiata e scalabile, ma più complessa.
👉 In scenari con picchi di traffico (es. flash sale) scelgo event-driven:
- Permette scalabilità indipendente di ogni servizio.
- Isola i guasti (se il magazzino è down, il pagamento continua a funzionare).
- Facilita l’aggiunta di nuovi consumatori (email, analytics, loyalty) senza modifiche al codice esistente.
2️⃣ Buy vs Build
La tua azienda deve lanciare un’app mobile con MFA, SSO ed elevata compliance (GDPR, HIPAA).
- Costruire in-house → massimo controllo ma costi enormi e rischi di sicurezza.
- Usare un provider (Auth0, Cognito) → lancio veloce, sicurezza “battle-tested”, aggiornamenti continui.
👉 In questo caso scelgo servizi terzi: sicurezza è difficile da implementare bene e le soluzioni esistenti sono mature e affidabili.
3️⃣ Monolite o microservizi?
Startup in fase iniziale, SaaS con gestione utenti, billing e notifiche.
👉 Preferisco partire con un monolite modulare:
- Sviluppo rapido e debugging semplice.
- Niente overhead iniziale di deploy e orchestrazione.
- Quando serve scalare, si estraggono i moduli in microservizi.
Grandi aziende come Facebook o Instagram hanno iniziato così.
4️⃣ SQL o NoSQL?
CRM con campi personalizzabili per i contatti.
👉 Se servono query complesse e reportistica, resto su SQL (PostgreSQL) con colonne JSON per flessibilità.
👉 Se prevale la necessità di schema dinamico e scalabilità rapida, scelgo NoSQL (MongoDB).
👉 A volte la soluzione giusta è ibrida: SQL per i dati core, NoSQL per la parte dinamica.
5️⃣ Cache o no cache?
Piattaforma di streaming con sistema di raccomandazioni pesante.
👉 Primo passo: cache Redis → miglioramento immediato, query da 2s a <100ms.
👉 Dopo la stabilizzazione: precomputazione asincrona per performance stabili e predicibili.
6️⃣ Come gestire un sistema legacy?
Applicazione monolitica di 20 anni.
👉 Riscriverla da zero è altamente rischioso.
👉 Scelgo refactoring incrementale:
- Creare interfacce stabili attorno ai componenti legacy.
- Estrarre gradualmente moduli ad alto impatto e basso rischio.
- Rafforzare testing e CI/CD per prevenire regressioni.
È meno “epico” di un rewrite totale, ma immensamente più sicuro ed efficace.
Best Practices per decisioni architetturali migliori
✅ Imparare dal passato: analizzare ADR e post-mortem per capire cosa ha funzionato e cosa no.
✅ Evitare l’hype: scegliere la tecnologia perché serve, non perché “va di moda”.
✅ Progettare per il cambiamento: modularità e disaccoppiamento permettono di evolvere senza riscrivere tutto.
✅ Prototipare prima di decidere: piccoli esperimenti evitano errori costosi.
✅ Pensare alla reversibilità: alcune scelte sono difficili da cambiare, valutare bene il rischio.
✅ Bilanciare breve e lungo termine: a volte serve un quick win, altre volte serve “farlo bene”.
✅ Essere pronti a correggere la rotta: sbagliare è normale, ciò che conta è iterare e migliorare.
Conclusione
Un’architettura “giusta” non è perfetta al primo colpo: è il risultato di scelte consapevoli, adattabilità e miglioramento continuo.
I migliori architetti non inseguono l’ultima moda, ma imparano, sperimentano e correggono.
👉 E tu? Quali strategie usi per prendere decisioni architetturali migliori?