Cambiavi il flusso di registrazione e si rompeva il carrello. Toccavi la logica dei pagamenti e il catalogo smetteva di caricare. Il team non poteva lavorare in parallelo perché tutto viveva nello stesso codebase, nello stesso deploy, nello stesso database. Ogni rilascio era un evento collettivo, con test manuali, preghiere e un piano B che consisteva nel fare rollback.

Il problema non era il codice in sé. Era che tutto dipendeva da tutto.

Il contesto

Il monolite era il cuore di una piattaforma e-commerce con social network integrato. Migliaia di utenti, decine di funzionalità intrecciate, un codebase che nessuno del team attuale aveva scritto. L'outsourcing aveva lasciato un'eredità pesante: poca documentazione, nessun test automatico, convenzioni inconsistenti, tabelle dedicate a un singolo vendor che sono evolute in tabelle di sistema mantenendo lo stesso nome.

Da architetto e CTO, il mio compito era trasformare quel sistema in qualcosa che potesse evolvere senza rompersi ad ogni deploy. Con un team che nel tempo è cresciuto fino a undici persone.

La scelta

La tentazione del "riscriviamo tutto da zero" era forte. Impossibile fermarsi. Troppo rischio, troppo tempo, e non ce l'avrebbero mai lasciato fare. L'approccio è stato lo strangler fig: svuotare il monolite pezzo per pezzo, estraendo funzionalità in microservizi, senza mai spegnere quello che già funzionava ma superarlo.

La prima domanda non era "cosa estraiamo?" ma "cosa ci fa più male?"

I domini con più accoppiamento, più bug, più rilasci bloccati: quelli prima.

Cosa ho fatto

Non tutto poteva essere disaccoppiato allo stesso modo. Alcune operazioni dovevano restare sincrone: il microservizio serviva il monolite, riceveva la richiesta, rispondeva in tempo reale. Per queste parti la chiave era scalare orizzontalmente, così che il nuovo servizio reggesse il carico senza diventare un collo di bottiglia.

Dove il disaccoppiamento poteva essere completo, SQS. Messaggi in coda, elaborazione asincrona, nessuna dipendenza temporale tra chi produce e chi consuma l'evento. Il monolite pubblicava un evento ("ordine creato", "utente registrato") e il microservizio lo gestiva per conto suo, nei suoi tempi.

Abbiamo valutato Kafka. L'idea era attraente: event streaming, replay, log immutabile. Ma nel nostro contesto i fastidi superavano i benefici. C'era troppo da sistemare prima di aggiungere un'infrastruttura complessa. SQS era managed, semplice, e risolveva il problema reale. A volte la scelta giusta è quella meno ambiziosa.

Il pattern era sempre lo stesso: identificare un dominio, definire i confini, estrarre il servizio, collegarlo con eventi o chiamate dirette a seconda del caso, verificare che il monolite continuasse a funzionare senza quella parte. Poi ripetere.

Risultati

Il monolite si è svuotato gradualmente. Ogni estrazione rendeva il sistema più stabile e il team più autonomo.

• Deploy indipendenti. Ogni team poteva rilasciare il proprio servizio senza aspettare gli altri. Niente più rilasci coordinati, niente più "aspetta che prima devo finire io."
• Meno rotture a catena. Un bug in un servizio non trascinava giù tutto il resto. L'isolamento funzionava.
• Velocità di sviluppo. Con confini chiari tra i domini, le persone sapevano dove mettere le mani senza paura di rompere qualcosa dall'altra parte.

L'azienda non esiste più, per ragioni che non c'entrano con la tecnologia. Ma il sistema, nel periodo in cui ha operato, ha retto.

Quando non serve

Non tutto va disaccoppiato. Un monolite che funziona, con un team piccolo e requisiti stabili, è una scelta perfettamente valida. Ho visto più danni da microservizi introdotti troppo presto che da monoliti lasciati in pace.

Il segnale che qualcosa deve cambiare è quando il costo del cambiamento nel sistema attuale supera il costo dell'estrazione. Quando ogni feature richiede il doppio del tempo perché metà lo passi a gestire effetti collaterali. Quando il deploy diventa un rischio invece che una routine.

Se non hai quel dolore, non hai quel problema. E se non hai quel problema, la prima cosa da fare è verificare che il problema esista davvero.

Se hai un monolite che ti tiene sveglio la notte, o un sistema dove tutto dipende da tutto e nessuno osa toccare niente... parliamone. Ti dico se vale la pena disaccoppiare, e da dove partire.