
Chi sono
Ingegnere, papà, karateka. Mi stanno a cuore sistemi facili da capire e team che la notte riescono a dormire.
La mia storia
Sono un backend engineer con base a Milano. Ho iniziato in consulenza, lavorando sui sistemi di grandi aziende italiane di telecomunicazioni e banking, dove ho capito quanto vale una migrazione fatta con cura quando milioni di persone dipendono da un servizio.
Poi è arrivato il digital trust — firme e marche temporali con valore legale in tutta Europa — e oggi il fintech in Satispay, dove seguo abbonamenti e loyalty. Domini diversi, stesso filo conduttore: sistemi che devono essere corretti, non solo veloci.
L’ingegneria conta di più per me quando unisce giudizio solido, comprensione condivisa e responsabilità per ciò che accade dopo il rilascio. Preferisco un documento di design chiaro a un’astrazione ingegnosa, e sono contento quando la reperibilità è noiosa.
Perché i sistemi backend
Ciò che mi ha appassionato fin dall’inizio ai sistemi backend è la concretezza dello stato: se un’interfaccia ha un glitch l’utente ricarica la pagina, ma se fallisce un motore di pagamenti o una firma digitale ci sono impatti finanziari e legali reali.
Mi piace lavorare dove i compromessi sono tangibili: bilanciare consistenza e latenza, decidere dove serve un confine sincrono e dove un disaccoppiamento a eventi, e progettare chiavi di idempotenza perché i retry di rete non creino mai effetti collaterali doppi.
Un buon sistema non è quello con il codice più ingegnoso: è quello in cui le modalità di guasto sono prevedibili, il monitoraggio dice la verità e il team può rilasciare di venerdì senza trattenere il respiro.
Come lavoro
- 01
Renderlo comprensibile
Confini chiari e compromessi onesti aiutano i team a muoversi più velocemente di astrazioni ingegnose.
- 02
Essere responsabili di ciò che si rilascia
La delivery include osservabilità, rilasci sicuri e vicinanza a come il sistema si comporta davvero.
- 03
Automatizzare con criterio
Gli strumenti devono togliere il lavoro ripetitivo mantenendo visibili decisioni e modalità di guasto.
Esperienza
SatispayAttuale
Software Engineer · Milano
Lavoro su abbonamenti e loyalty — sviluppando servizi in Spring Boot su infrastruttura AWS e interfacce in React per i flussi utente. Il mio compito è fare in modo che nessuno paghi due volte e che nessun punto vada perso.
La storia dietro
- La situazione
- I pagamenti ricorrenti crescevano in fretta e con loro il rischio di bug di concorrenza e di saldi fedeltà disallineati tra i servizi.
- L’obiettivo
- Ripensare la gestione di abbonamenti e punti fedeltà perché il sistema resti corretto e prevedibile anche nei picchi di traffico.
- Cosa ho fatto
- Sviluppato servizi Spring Boot su AWS con pattern CQRS, transactional outbox via SNS & SQS per il disaccoppiamento degli eventi e flussi React integrati con chiavi di idempotenza.
- Il risultato
- Disponibilità al 99,99%, zero addebiti doppi e latenza P99 al checkout ridotta del 40%.
Namirial
Software Engineer — Digital Trust · Milano / Remoto
Quattro anni sui sistemi dietro firme digitali e marche temporali (RFC 3161) con valore legale in tutta Europa — software in cui “quasi corretto” non basta.
La storia dietro
- La situazione
- Il motore di verifica delle marche temporali rallentava nei picchi di carico, mettendo a rischio gli SLA di conformità eIDAS.
- L’obiettivo
- Modernizzare la pipeline crittografica ed eliminare la contesa sul database — senza mai spegnere il servizio.
- Cosa ho fatto
- Ho spezzato i colli di bottiglia del monolite in flussi di eventi asincroni, introdotto lo sharding del database senza downtime e ottimizzato i thread di firma.
- Il risultato
- Latenza P99 di verifica ridotta del 65%, oltre 10 milioni di operazioni crittografiche al giorno, conformità di audit al 100%.
Digipax
Software Architect — Identity & Logistics · Remoto
In parallelo a Namirial, ho progettato il livello di autenticazione e i gateway backend-for-frontend di una piattaforma logistica che gira sia in cloud sia sui server dei clienti.
La storia dietro
- La situazione
- I clienti enterprise della logistica dovevano poter installare on-premise o in cloud, con un isolamento rigoroso tra tenant.
- L’obiettivo
- Fornire un’unica architettura backend che gestisse scambio di token OAuth2/OIDC e sicurezza edge per ogni modello di deployment.
- Cosa ho fatto
- Ho progettato un monolite modulare con confini di dominio chiari, mTLS sull’edge e infrastruttura interamente automatizzata come codice.
- Il risultato
- L’onboarding di un nuovo tenant enterprise è passato da settimane a ore, e i rilasci hanno smesso di essere stressanti.
Spindox
Software Engineer — Enterprise Systems · Milano
Dove ho imparato il mestiere: modernizzare sistemi backend per grandi clienti italiani come SIAE, TIM, Intesa Sanpaolo e Fastweb.
La storia dietro
- La situazione
- I monoliti legacy di grandi clienti telco e banking rendevano ogni rilascio lento e ogni deploy un rischio.
- L’obiettivo
- Scomporre i monoliti in servizi senza mai interrompere un servizio attivo 24/7.
- Cosa ho fatto
- Ho migrato un pezzo alla volta con il pattern strangler-fig, introdotto il tracing distribuito con OpenTelemetry e standardizzato le pipeline CI/CD.
- Il risultato
- Da rilasci mensili a rilasci quotidiani, e rollback critici azzerati.
Fuori dal lavoro
- Papà
Famiglia
Mia figlia porta prospettiva, energia e scopo ogni giorno.
- Due gatti e un cane
Casa
Una casa vivace, mai a corto di interruzioni o carattere.
- Pratica e insegnamento
Karate
Una disciplina di lungo corso fatta di pazienza, ripetizione e affinamento continuo.