Per una grande impresa italiana del settore Finance, Seacom ha realizzato un sistema di ricerca di transazioni bancarie capace di gestire milioni di operazioni al giorno. La soluzione doveva garantire rapidità e precisione nella ricerca, oltre all’usabilità per operatori non tecnici. L’architettura combina Apache Kafka, con i moduli Kafka Streams e Kafka Connect, per l’ingestione e l’elaborazione dei dati in streaming, e OpenSearch, con OpenSearch Dashboards, per l’indicizzazione, la ricerca e la visualizzazione. Il beneficio principale è la possibilità di effettuare ricerche di dettaglio in near real time su centinaia di milioni di transazioni, con controlli di sicurezza granulari.

La sfida era creare un sistema capace di indicizzare e restituire in tempo reale enormi volumi di dati, garantendo stabilità del cluster e facilità d’uso per utenti non tecnici. Il cliente richiedeva inoltre un’architettura flessibile e scalabile, in grado di gestire decine di milioni di transazioni giornaliere provenienti da un database Oracle sorgente, con meccanismi di controllo della sicurezza per proteggere i dati sensibili delle transazioni. Erano necessari inoltre modelli di ricerca avanzata, capacità di aggregazione e filtraggio dei dati, e un sistema di sicurezza granulare a livello di singolo campo e documento per rispettare i requisiti del settore finanziario.

L’architettura utilizza Apache Kafka per l’ingestione dei dati in streaming: Kafka Streams elabora e arricchisce i dati in tempo reale, mentre Kafka Connect li trasferisce a OpenSearch per l’indicizzazione, a partire da uno script di normalizzazione dati collegato a un database Oracle sorgente. OpenSearch Dashboards fornisce la componente visiva per la consultazione e il monitoraggio, con ricerche avanzate tramite filtri specifici. Su OpenSearch sono stati definiti indici temporali giornalieri per distribuire uniformemente il carico e migliorare i tempi di risposta del cluster, gestendo decine di milioni di transazioni al giorno. L’architettura adotta una struttura hot-cold: le transazioni recenti risiedono su nodi hot ad alte prestazioni, mentre i dati più vecchi vengono spostati su nodi cold per ridurre il carico sui nodi principali. La sicurezza è garantita tramite Field-Level-Security e Document-Level-Security, con policy ISM per la gestione automatizzata del ciclo di vita degli indici e un meccanismo di identificazione delle frodi tramite le API di OpenSearch.