Aldo Lushkja

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

  1. 01

    Renderlo comprensibile

    Confini chiari e compromessi onesti aiutano i team a muoversi più velocemente di astrazioni ingegnose.

  2. 02

    Essere responsabili di ciò che si rilascia

    La delivery include osservabilità, rilasci sicuri e vicinanza a come il sistema si comporta davvero.

  3. 03

    Automatizzare con criterio

    Gli strumenti devono togliere il lavoro ripetitivo mantenendo visibili decisioni e modalità di guasto.

Esperienza

  1. 2025 — oggi1 anno e 1 mese

    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%.

    AWS (SNS & SQS) · Spring Boot · React · Architettura a eventi · Idempotenza

  2. 2021 — 20254 anni e 2 mesi

    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%.

    Crittografia · Pipeline ad alto volume · Sharding database · eIDAS

  3. 2022 — 20252 anni e 10 mesi

    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.

    Pattern BFF · Multi-tenancy · Monolite modulare · OAuth2 / OIDC

  4. 2018 — 20212 anni e 8 mesi

    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.

    Migrazione a microservizi · OpenTelemetry · CI/CD · Strangler-fig

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.

Mi trovi anche qui