Il tuo monolite va benissimo. Smettila di voler fare microservizi.

C'è un momento nella vita di ogni startup in cui qualcuno — di solito lo sviluppatore più entusiasta del team — propone di passare ai microservizi. "Il monolite non scala", dice. "Netflix usa i microservizi", dice. "Dobbiamo prepararci alla crescita", dice. E da lì parte un progetto di migrazione che costerà mesi, non risolverà il problema, e ne creerà di nuovi.

Se il tuo prodotto funziona come monolite, probabilmente dovrebbe restare un monolite. Non perché i microservizi siano sbagliati, ma perché risolvono un problema che tu molto probabilmente non hai.

Il problema che i microservizi risolvono davvero

I microservizi sono nati per risolvere un problema organizzativo, non tecnico.

Quando Netflix, Amazon o Google hanno centinaia di team che lavorano sullo stesso prodotto, il monolite diventa un collo di bottiglia umano. Ogni deploy richiede coordinazione tra team. Un bug in un modulo blocca il rilascio di tutti gli altri. Le riunioni di sincronizzazione mangiano più tempo dello sviluppo stesso.

I microservizi risolvono questo: ogni team possiede il proprio servizio, lo deploya indipendentemente, e comunica con gli altri attraverso API ben definite. Il costo è la complessità del sistema distribuito. Il beneficio è l'indipendenza dei team.

Se hai meno di 30-40 sviluppatori, questo problema non ce l'hai. Il tuo team si coordina a voce, i deploy sono gestibili, e la complessità aggiuntiva dei microservizi non compensa nessun vantaggio organizzativo.

Cosa succede davvero quando adotti i microservizi troppo presto

La complessità operativa esplode

Un monolite è un processo, un database, un deploy. Un'architettura a microservizi è decine di processi, potenzialmente decine di database, decine di pipeline di deploy, e un'infrastruttura di rete che li collega tutti.

Servono: service discovery, load balancing tra servizi, circuit breaker per gestire i fallimenti, tracing distribuito per capire dove si blocca una richiesta che attraversa 5 servizi, logging centralizzato per raccogliere i log da tutti i nodi. E qualcuno deve manutenere tutto questo.

Il tuo team di 5 persone, che prima spendeva il 100% del tempo sulle feature, ora ne spende il 40% a tenere in piedi l'infrastruttura. Complimenti: hai appena dimezzato la velocità di sviluppo per risolvere un problema che non avevi.

Il debugging diventa un incubo

Nel monolite, un errore ha uno stack trace. Lo leggi, capisci dov'è il problema, lo risolvi.

Nei microservizi, una richiesta utente attraversa 4 servizi. L'errore potrebbe essere in qualunque di essi, nella comunicazione tra di essi, nel message broker, nel timeout di rete, o in un race condition che si manifesta solo quando due servizi rispondono in un ordine specifico.

Il tempo medio di risoluzione di un bug in un sistema distribuito è 3-10 volte più lungo che in un monolite. Per un team piccolo, questo è devastante.

La consistenza dei dati diventa un problema

Nel monolite hai una transazione. Inizi, fai le operazioni, commit o rollback. I dati sono sempre consistenti.

Nei microservizi, ogni servizio ha il suo database. Una operazione che tocca due servizi richiede un pattern di consistenza eventuale — saga, outbox, compensazione. Devi gestire il caso in cui il primo servizio ha completato ma il secondo fallisce. Devi decidere cosa mostrare all'utente nel frattempo.

Questo non è impossibile. Ma è complessità reale che prima non avevi e che ora devi progettare, implementare, testare, e manutenere. Per ogni singola operazione cross-service.

"Ma il monolite non scala!"

Questa è la bugia più diffusa.

Un monolite ben scritto scala verticalmente (server più potente) e orizzontalmente (più istanze dietro un load balancer) senza problemi. Laravel, Rails, Django — tutti possono gestire migliaia di richieste al secondo su un singolo server moderno. Con un load balancer e 3-4 istanze, arrivi a decine di migliaia.

Sai quante richieste al secondo ha il tuo prodotto? Se non lo sai, probabilmente sono meno di quanto pensi. La maggior parte delle web app con 50.000 utenti attivi genera poche centinaia di richieste al secondo. Un singolo server le gestisce tranquillamente — ammesso che le query al database siano ottimizzate.

Il collo di bottiglia, nel 90% dei casi, non è l'architettura. È il database. Query inefficienti, N+1 nascosti, indici mancanti. E quelli li hai sia nel monolite che nei microservizi — anzi, nei microservizi li hai in ogni singolo servizio.

Quando i microservizi hanno senso (davvero)

Ci sono situazioni in cui i microservizi sono la scelta giusta:

Team grandi (30+ sviluppatori) dove la coordinazione è diventata il collo di bottiglia principale. Se i deploy richiedono settimane di sincronizzazione, i microservizi risolvono un problema reale.

Requisiti di scaling radicalmente diversi tra componenti. Se il servizio di elaborazione video deve scalare a 100 istanze mentre il resto dell'app ne usa 2, separarlo ha senso.

Requisiti tecnologici diversi tra componenti. Se una parte del sistema deve essere in Python per il machine learning e il resto è in PHP, un confine di servizio è naturale.

Nota cosa hanno in comune: sono problemi che emergono dopo che il prodotto ha avuto successo, non prima. Progettare per microservizi al giorno zero è come comprare un autobus perché "un giorno potremmo avere molti passeggeri". Intanto sei solo tu in un autobus, e il parcheggio costa una fortuna.

Cosa fare invece dei microservizi

Se il tuo monolite sta diventando difficile da gestire, la soluzione quasi sempre non è spezzarlo. È strutturarlo meglio.

Moduli ben definiti. Organizza il codice per domini di business con confini chiari. In Laravel, usa domain directories. In Symfony, usa bounded contexts. Il codice è nello stesso deploy, ma logicamente separato.

API interne. Fai comunicare i moduli attraverso interfacce esplicite, non importando classi a caso. Quando e se un giorno dovrai estrarre un servizio, il confine è già definito.

Database ottimizzato. Prima di pensare all'architettura, assicurati che il database non sia il vero problema. Nella mia esperienza, il 90% dei problemi di "scala" si risolve ottimizzando le query, non cambiando architettura.

Deploy frequenti. Se il problema è che i deploy sono rischiosi, investi in CI/CD, test automatici, e deploy incrementali. Non in un'architettura che moltiplica i deploy per il numero di servizi.

Per chi prende decisioni

Se qualcuno nel tuo team sta proponendo di migrare ai microservizi, fai queste domande:

• Qual è il problema specifico che stiamo risolvendo? Se la risposta è vaga ("scalabilità", "modernizzazione"), è un red flag.
• Abbiamo le competenze operative? Servono skills di DevOps, Kubernetes, networking, monitoring distribuito. Se non le avete, dovrete assumerle o formarle.
• Quanto costerà la migrazione? Moltiplica la stima per 3. Non è cinismo — è la realtà delle stime nel software.
• Il problema si può risolvere diversamente? Quasi sempre la risposta è sì.

Il monolite ben fatto è un vantaggio competitivo

Nel 2026, con l'AI che accelera lo sviluppo, un monolite ben strutturato è un vantaggio. Un singolo codebase che l'AI può comprendere interamente, dove le relazioni tra moduli sono esplicite, dove il debug è lineare. Contro un sistema distribuito dove l'AI deve navigare tra servizi, capire protocolli di comunicazione, e gestire stati distribuiti.

La semplicità non è una limitazione. È una feature. E nel software, le feature più sottovalutate sono spesso quelle che ti fanno dormire la notte.

Se stai valutando l'architettura del tuo prodotto e qualcuno sta spingendo per i microservizi, parliamone. Ti aiuto a capire se hai davvero quel problema o se la soluzione è molto più semplice di quello che ti stanno proponendo.