Decisioni tecniche, postmortem e numeri reali dal cluster che muove 45M visite/mese.
Aprile 2024. Dovevamo indicizzare 50 milioni di articoli sul cluster Typesense di AI Multisite. Il piano sembrava ragionevole. L’errore l’abbiamo visto in produzione: schema troppo grasso, RAM in saturazione.
Febbraio 2024. Due app server, due database editoriali grandi, MaxScale davanti, una replica circolare master-master tra james-db e jason-db. Il giorno che ho smesso di rispondere alle 5 del mattino agli alert e perché farei la stessa scelta architetturale oggi.
Gennaio 2024, sedici server HestiaCP da migrare da PHP 7.4 a 8.4 in due settimane, ~120 siti WordPress di clienti, zero ore di downtime contrattuale. Il piano rolling, il workflow, e tre incidenti reali in produzione: count(null) di un plugin, opcache mismatch, WP-CLI globale fuori sync. Postmortem onesto: PHP 7.4 a 8.4 fleet 16 server.
Agosto 2023, primi mesi di Romiltec. Un template HestiaCP riproducibile che porta un cliente WordPress nuovo da server vuoto a produzione in un’ora: SSL automatico, mail con DKIM, backup off-site cifrati, tuning nginx. Logica, stack, e i due bug che ho dovuto correggere dopo il primo cliente reale: hestia control panel baseline cliente.
Agosto 2023, primi mesi di Romiltec. Otto server bare-metal, HestiaCP su tutti, niente orchestrator. Le scelte che rifarei, quelle che ho pagato in operations e perché Hestia resta il punto di partenza giusto per una software house bootstrap.
Cosa ho copiato e cosa ho buttato dopo otto anni a guidare un’infrastruttura Laravel/MariaDB/MaxScale in una software house del territorio pisano. Lo stack iniziale di Romiltec, scelta per scelta.