Tendex — Piattaforma di investimento per il mercato degli asset digitali

L'interfaccia esistente della piattaforma era obsoleta, poco pratica per gli investitori e non rifletteva lo status di un fondo svizzero regolamentato. Era necessario rinnovare la parte visiva e l'UX senza perdere funzionalità e senza interferire con i processi di business in corso.

• Audit dei template Twig esistenti e identificazione dei componenti riutilizzabili.
• Sviluppo di un nuovo design system: griglia, tipografia, componenti UI.
• Reimplementazione delle pagine chiave con Twig e integrazione di componenti Vue per le aree interattive (grafici, tabelle, form).
• Garanzia della responsività e del rendering corretto su dispositivi mobili.

Gli investitori o gli amministratori dovevano poter chiudere anticipatamente un piano di investimento, con un ricalcolo corretto di rendimento, commissioni e rimborso. Bisognava evitare la desincronizzazione dei dati durante operazioni parallele.

• Progettazione di un modello di dominio per la chiusura del piano che copre tutti gli stati (attivo, congelato, in coda).
• Implementazione di un servizio per il calcolo del rendimento finale e delle commissioni.
• Spostamento delle operazioni pesanti in task asincroni tramite RabbitMQ.
• Aggiunta di idempotenza delle operazioni e lock tramite Redis.

La semplice cancellazione di un utente rompeva le entità collegate (piani di investimento, transazioni, referral). Era necessario implementare una cancellazione sicura che preservasse lo storico finanziario e i requisiti normativi.

• Introduzione di un meccanismo di soft-delete per gli utenti preservando le relazioni.
• Progettazione di un'elaborazione a cascata: anonimizzazione dei dati personali, preservazione dello storico delle transazioni.
• Implementazione di un task in background per la pulizia delle entità collegate tramite RabbitMQ.
• Aggiunta di logging e audit delle operazioni di cancellazione.

Gli investitori avevano bisogno di poter sospendere temporaneamente l'accumulo di rendimento di un piano senza chiuderlo — ad esempio in caso di instabilità del mercato. Tali periodi dovevano essere correttamente considerati nei calcoli.

• Aggiunta dello stato «congelato» nel ciclo di vita del piano di investimento.
• Implementazione della logica di pausa degli accumuli e ripresa corretta.
• Aggiornamento del calcolo del rendimento per tenere conto dei periodi di congelamento.
• Aggiunta di notifiche all'investitore sullo stato del piano.

Gli investitori volevano creare un piano in anticipo con avvio automatico a una data specificata. Era necessaria una pianificazione affidabile dei task, robusta a guasti e riavvii dei servizi.

• Implementazione dell'avvio differito tramite lo scheduler Symfony + RabbitMQ delayed messages.
• Aggiunta di un'elaborazione idempotente dell'avvio (protezione dal doppio avvio).
• Monitoraggio dei task differiti e logging.
• Implementazione di notifiche all'investitore sull'avvio.

Il sistema di referral richiedeva flessibilità: gli amministratori dovevano poter modificare l'assegnazione dei referral e gli investitori vedere la struttura attuale. L'implementazione esistente non permetteva di modificare le assegnazioni senza perdere lo storico degli accumuli.

• Progettazione di un modello di relazioni referral con versioning.
• Implementazione di un'interfaccia di modifica dei referral per gli amministratori.
• Preservazione dello storico degli accumuli al cambio di assegnazione.
• Aggiunta di validazione contro dipendenze cicliche.

La crescita del carico e del numero di operazioni (accumuli, avvio/stop di piani, notifiche) richiedeva di spostare le operazioni pesanti fuori dal ciclo HTTP sincrono per non bloccare le richieste degli utenti.

• Progettazione di una coda di eventi per le operazioni di dominio chiave.
• Implementazione di worker con Symfony Messenger + RabbitMQ.
• Aggiunta di policy di retry, dead-letter queue e monitoring.
• Garanzia dell'idempotenza degli handler.

La ricerca rapida su grandi volumi di dati (transazioni, piani, utenti) e la costruzione di analytics richiedevano un motore di ricerca specializzato invece di query SQL pesanti.

• Configurazione degli indici ElasticSearch per le entità chiave.
• Implementazione della sincronizzazione dei dati tramite eventi RabbitMQ.
• Aggiunta di query di ricerca con filtri e aggregazioni per l'analytics.
• Ottimizzazione di mapping e reindicizzazione.

L'elevata frequenza di accesso ai dati di uso frequente e la necessità di proteggersi da race condition durante operazioni parallele richiedevano una cache affidabile e un meccanismo di lock.

• Introduzione del caching dei dati caldi e degli aggregati in Redis.
• Implementazione di lock distribuiti per le operazioni critiche (avvio/chiusura dei piani).
• Configurazione dell'invalidazione della cache tramite eventi.
• Aggiunta di monitoring hit/miss e tempi di risposta.

Un fondo regolamentato richiede un audit completo di tutte le operazioni finanziarie: chi, quando, cosa e su quale base. Era necessario costruire un sistema di audit che non rallentasse i processi principali.

• Progettazione di uno schema di audit log collegato a utente, piano e transazione.
• Implementazione della scrittura asincrona dell'audit tramite RabbitMQ.
• Aggiunta di strumenti di ricerca ed export degli audit log per gli amministratori (ElasticSearch).
• Garanzia dell'immutabilità dei record.

La piattaforma di investimento opera 24/7 e qualsiasi ritardo nell'elaborazione degli eventi o guasto di un worker è critico. Era necessario un sistema di monitoring delle metriche chiave e di alert.

• Configurazione della raccolta di metriche su code (RabbitMQ), Redis, ElasticSearch ed eventi di business chiave.
• Implementazione di alert su anomalie (crescita della DLQ, ritardi, errori dei worker).
• Aggiunta di dashboard per il team.
• Integrazione del logging delle operazioni critiche.