Il Contesto
Il progetto e stato realizzato per una startup fintech europea che voleva portare sul mercato un prodotto a meta strada tra il gaming competitivo e il trading reale: un'app mobile in cui l'utente apre una sessione a tempo (cinque minuti) e prova a leggere correttamente il movimento di un asset di mercato, con un esito misurato su dati di prezzo veri e non simulati. Per ragioni di riservatezza il nome della startup, i volumi di transazione e gli accordi commerciali non vengono divulgati.
Il pubblico di riferimento e mobile-first e abituato all'immediatezza degli exchange di criptovalute: si aspetta un grafico che si muove in tempo reale, un esito chiaro alla fine della sessione e un deposito o un pagamento che funziona al primo tentativo. Questo fissa, fin dall'inizio, due vincoli non negoziabili: affidabilita del dato di mercato e affidabilita del pagamento.
Il Problema
Una piattaforma di questo tipo concentra in pochi minuti tutte le criticita tecniche dura del fintech. Le tre piu rilevanti, definite con il team della startup all'avvio:
- Il dato di mercato deve essere lo stesso per tutti: se due utenti aprono la stessa sessione nello stesso istante, devono vedere lo stesso prezzo. Un feed disallineato o in ritardo non e un fastidio cosmetico, e una contestazione su un esito che vale denaro reale.
- La sessione e a tempo, e il tempo deve essere autoritativo: il conto alla rovescia di cinque minuti non puo dipendere dall'orologio del telefono dell'utente, altrimenti diventa manipolabile. Apertura, prezzo di entrata e prezzo di chiusura devono essere stabiliti e congelati lato server.
- I pagamenti devono reggere il modello di business reale: deposito, eventuale payout e gestione degli stati intermedi (pagamento in sospeso, fallito, rimborsato) vanno tracciati in modo idempotente, perche in un flusso real-time un webhook duplicato o fuori ordine e la norma, non l'eccezione.
Sopra a tutto questo, il vincolo di prodotto: l'esperienza doveva restare fluida su mobile anche in condizioni di rete instabile, perche l'utente target gioca in metropolitana o in pausa pranzo, non davanti a una connessione cablata.
La Soluzione
L'architettura e stata disegnata a microservizi, separando in modo netto le responsabilita che hanno cicli di vita e profili di carico diversi: il feed di mercato, la logica di sessione e i pagamenti non devono mai cadere insieme.
Market data service
Un servizio dedicato mantiene una connessione WebSocket verso Binance e funge da unica fonte di verita per il prezzo. Invece di far aprire a ogni client la propria connessione all'exchange, il servizio normalizza il flusso a monte e lo ridistribuisce ai client connessi. Cosi tutti gli utenti di una stessa sessione condividono lo stesso ticker, e il prezzo di entrata e di uscita viene timbrato dal server nell'istante esatto di apertura e chiusura della sessione.
Session service
Il cuore di gioco e un servizio NestJS che possiede il ciclo di vita della sessione da cinque minuti: crea la sessione, congela il prezzo d'ingresso, gestisce il countdown autoritativo e, alla scadenza, calcola l'esito confrontando il prezzo di chiusura con quello d'ingresso. Lo stato e persistito su MongoDB, scelta naturale per documenti di sessione con TTL e per la velocita di scrittura richiesta dal carico a raffica.
Payment service e gateway real-time
L'integrazione con Stripe e isolata in un servizio a se, che espone gli endpoint di deposito e gestisce i webhook in modo idempotente. Verso il frontend, un gateway su Fastify mantiene il canale WebSocket a bassa latenza, instradando prezzi e aggiornamenti di stato della sessione senza che il client debba fare polling. Tutto e containerizzato con Docker per garantire che lo stesso identico ambiente giri in sviluppo e in produzione.
Frontend mobile-first
L'app e costruita in Vue 3 con Tailwind, pensata prima per il pollice e poi per il desktop: grafico live, countdown e stato del pagamento aggiornati in tempo reale via WebSocket, con riconnessione automatica e ripristino dello stato di sessione quando la rete torna disponibile.
Tecnologie Chiave
Lo stack privilegia tecnologie a basso overhead di latenza e robuste sotto carico a raffica, con un solo linguaggio (TypeScript/JavaScript) condiviso tra backend e frontend per ridurre il context switch.
NestJS
Backend dei microservizi con confini di responsabilita netti per la logica di sessione.
Fastify
Gateway HTTP/WebSocket ad alte prestazioni, scelto per l'overhead minimo per richiesta.
MongoDB
Persistenza dei documenti di sessione con TTL, ottimizzata per scritture frequenti.
WebSocket (Binance)
Feed di prezzo live come unica fonte di verita, normalizzato e ridistribuito ai client.
Vue 3
Frontend mobile-first reattivo, con aggiornamenti real-time del grafico e dello stato.
Tailwind
UI consistente e veloce da iterare, ottimizzata per l'interazione a pollice su mobile.
Stripe
Pagamenti in produzione con webhook gestiti in modo idempotente per stati e rimborsi.
Docker
Containerizzazione per parita tra ambienti e deploy ripetibile dei microservizi.
Il Risultato
La piattaforma e stata portata in produzione come prodotto completo e funzionante, con transazioni reali. Questi sono gli esiti chiave del progetto.
Mercato real-time via WebSocket
Pagamenti in produzione
Frontend Vue 3
Gli indicatori riportati sono indicativi e stimati, su progetto soggetto a riservatezza: descrivono capacita tecniche effettivamente rilasciate, non cifre commerciali o di transazione, che non vengono divulgate.
Sfide Tecniche
1. Un prezzo coerente per tutti, timbrato dal server
Lasciare che ogni client si connettesse direttamente a Binance avrebbe prodotto piccoli disallineamenti di timing e di prezzo tra utenti: inaccettabile quando l'esito vale denaro. La soluzione e stata centralizzare il feed in un singolo market data service che mantiene la connessione all'exchange, normalizza il tick e lo ridistribuisce. Il prezzo d'ingresso e di chiusura della sessione viene congelato lato server all'apertura e alla scadenza del countdown, non sul dispositivo. Cosi l'esito e deterministico e ricostruibile, e il countdown a tempo non e manipolabile dal client.
2. Pagamenti idempotenti in un flusso real-time
In un contesto a microservizi con webhook, gli eventi di pagamento arrivano duplicati, fuori ordine o in ritardo: e fisiologico. Trattarli in modo ingenuo significa addebitare due volte o segnare come pagata una sessione fallita. Ogni evento Stripe e stato reso idempotente, con uno stato del pagamento autoritativo lato payment service che riconcilia i webhook in arrivo invece di fidarsi del loro ordine. Isolare i pagamenti in un microservizio dedicato ha inoltre permesso di iterare sul gioco senza mai toccare il codice che maneggia denaro.
Il filo conduttore di entrambe le sfide e lo stesso principio: in fintech la fonte di verita non puo mai stare sul client. Prezzo, tempo e stato del pagamento appartengono al server.
