Modernizzare un monolite Zend senza rompere il fatturato
Strangler pattern, eventi, code, e un team che non può fermarsi una settimana. La nostra strategia su un eCommerce da 8 cifre.
Il cliente fattura otto cifre l'anno su un monolite Zend Framework 1 che nessuno tocca da otto anni. Il team interno conosce il codice ma non può fermarsi una settimana per riscriverlo. Servizio in produzione 24/7, picchi nei weekend.
Abbiamo applicato lo strangler pattern: il monolite resta, ma ogni nuova funzionalità nasce fuori. Un gateway davanti instrada le chiamate al vecchio o al nuovo a seconda della route. Niente big bang, solo migrazione graduale modulo per modulo.
Eventi e code (Redis + Laravel Horizon) disaccoppiano i processi pesanti — fatturazione, sincronizzazione marketplace, email transazionali. Il monolite scrive un evento, il nuovo stack lo consuma. Se qualcosa si rompe, il monolite continua a vendere.
Il modulo più critico — checkout — è stato l'ultimo a essere migrato, dopo un anno di lavoro sui contorni. Feature flag, canary release sull'1% del traffico, rollback istantaneo. Zero downtime, zero ordini persi.
Lezione: la modernizzazione non è una migrazione, è una convivenza prolungata. Chi promette di riscrivere tutto in tre mesi non ha mai visto un legacy serio.
Ogni segnale nasce da un progetto reale.