Comunicazione dei Dati nei Sistemi di Algo Trading: Una Panoramica Tecnologica

Nel trading algoritmico, la differenza tra profitto e perdita può essere misurata in microsecondi. L'architettura di trasmissione dei dati è uno dei fattori chiave che determinano l'efficienza di un sistema di trading. In questo articolo analizzeremo le tecnologie di comunicazione a tutti i livelli: dall'interazione con l'exchange alla comunicazione interna tra servizi, allo storage e alla distribuzione dei dati.

L'articolo è organizzato per livelli — da "esterno" (protocolli degli exchange) a "interno" (IPC, message broker, storage) — riflettendo la reale architettura di una piattaforma di trading algoritmico.

1. Interazione con l'Exchange: REST, WebSocket, FIX

1.1 REST API

REST è il modo più semplice e comune per interagire con le API di un exchange. Ogni richiesta è una connessione HTTP separata: handshake TCP → handshake TLS → invio della richiesta → ricezione della risposta → chiusura della connessione.

Problemi di REST per il Trading:

Ogni richiesta comporta l'overhead dell'impostazione della connessione. Anche con HTTP keep-alive, il modello "request-response" significa che non è possibile ricevere dati più velocemente di quanto si inviano richieste. Questo porta al polling — un ciclo continuo di query "ci sono nuovi dati?" che creano fino all'80% del carico sui server degli exchange (secondo gli sviluppatori di exchange crypto). Gli exchange introducono rate limit (tipicamente 10–1200 richieste al minuto), rendendo REST inadatto alle strategie ad alta frequenza.

Quando REST è appropriato: recupero di dati storici (candele, OHLCV), gestione degli account (saldo, posizioni), operazioni non in tempo reale (bot DCA, ribilanciamento orario).

1.2 WebSocket

WebSocket stabilisce una singola connessione TCP persistente attraverso cui i dati fluiscono bidirezionalmente. Inizia come una normale richiesta HTTP con un header Upgrade, poi passa a un protocollo di framing bidirezionale (il payload può essere JSON testuale o binario).

Vantaggi per il Trading:

Il vantaggio principale è l'assenza di overhead per ogni richiesta. Una volta stabilita la connessione, i dati vengono inviati istantaneamente dal server. La latenza di consegna dei dati di mercato via WebSocket è tipicamente inferiore a 50 ms dal gateway dell'exchange al client. È possibile sottoscriversi a 50+ simboli simultaneamente su un'unica connessione.

Un punto critico: gli ordini via WebSocket. Molti trader non sanno che alcuni exchange (Binance, HitBTC, Deribit, Bybit, ecc.) consentono di inviare ordini via WebSocket, non solo di ricevere dati. Questo è fondamentalmente più veloce di REST perché:

• Nessun handshake TCP/TLS per ogni ordine (la connessione è già "calda")
• Nessun overhead HTTP (header, cookie, ecc.)
• Modello asincrono: si invia un ordine e si riceve la conferma attraverso lo stesso WebSocket senza bloccare il thread.

Secondo Deribit, WebSocket e FIX hanno spesso la stessa velocità di esecuzione. REST è leggermente più lento a causa del preprocessing a livello di connessione. Gli ordini WebSocket raggiungono la coda del matching engine esattamente come gli ordini FIX.

Problema del Mixing Context. Se si inviano ordini via REST ma si ricevono le notifiche di esecuzione via WebSocket, si verifica una race condition: la notifica WebSocket potrebbe arrivare prima che la richiesta REST venga completata. Questo porta a inconsistenze di stato. La soluzione è inviare gli ordini attraverso lo stesso WebSocket, passando completamente a un modello asincrono.

1.3 Protocollo FIX (Financial Information eXchange)

FIX è lo standard industriale per il trading elettronico, esistente dal 1992 (creato da Fidelity Investments e Salomon Brothers). È un protocollo binario su TCP specificamente progettato per il trading.

Architettura FIX:

• Session layer — gestisce la connessione, gli heartbeat, la numerazione delle sequenze e il recupero dei gap. Garantisce la consegna e l'ordine dei messaggi.
• Application layer — logica di business: tipi di ordine, report di esecuzione, richieste di dati di mercato.

I messaggi FIX sono composti da coppie "tag=valore" separate da un carattere SOH. Ad esempio, un ordine di acquisto di 100 azioni di AAPL a $150 appare così:

8=FIX.4.2|35=D|49=BUYER|56=SELLER|11=ORD1001|38=100|40=2|54=1|55=AAPL|44=150.00

Perché FIX è più veloce di WebSocket: FIX è un protocollo TCP nativo senza livelli HTTP. AWS, nella sua guida all'ottimizzazione tick-to-trade per gli exchange crypto, raccomanda esplicitamente FIX rispetto a REST e WebSocket per minimizzare la latenza indotta dal protocollo. FIX opera a livello di microsecondi, mentre WebSocket è tipicamente in millisecondi.

Dove FIX domina: DMA (Direct Market Access) al matching engine dell'exchange, trading algoritmico e HFT in ambito istituzionale, aggregazione della liquidità (prime broker collegati a decine di banche via FIX).

Limitazioni di FIX: complessità di integrazione, formato dei messaggi obsoleto (i tag-value testuali sono meno efficienti dei formati binari), alta barriera all'ingresso. Nel settore crypto, FIX è supportato da un numero limitato di exchange.

1.4 SBE (Simple Binary Encoding) — FIX Evolutivo

SBE è un formato di serializzazione binaria creato dall'High Performance Working Group all'interno della FIX Trading Community. La sua missione è sostituire il formato FIX testuale con una rappresentazione binaria compatta per il trading a latenza ultra-bassa.

Principi Chiave di SBE:

• Zero-copy flyweight pattern — encoder e decoder agiscono come "template" su un buffer. I valori vengono scritti direttamente senza copie intermedie (a differenza di Protobuf, che ne richiede diverse).
• Wire format = memory format — i dati sul wire appaiono esattamente come in memoria, minimizzando l'overhead di trasformazione.
• Campi fissi prima, campi variabili dopo — un vincolo di design che offre prestazioni di un ordine di grandezza superiori rispetto a Protocol Buffers.

SBE + Aeron è la combinazione standard per i sistemi di trading ad alte prestazioni. Aeron è un sistema di messaggistica open-source di Real Logic (creato da Martin Thompson, ex CTO di LMAX Exchange, e Todd Montgomery, ex CTO di 29West/Ultra Messaging). È effettivamente un livello di trasporto specializzato per i sistemi finanziari che lavora su UDP e memoria condivisa con latenze nell'ordine di singole cifre di microsecondi. SBE gestisce la serializzazione, mentre Aeron gestisce la consegna con ritardi in microsecondi. Maggiori dettagli su Aeron nella sezione 3.1.

1.5 Tabella Comparativa dei Protocolli Exchange

2. Comunicazione Interna tra Microservizi

Una volta che i dati entrano nel sistema dall'exchange, inizia l'elaborazione interna: parsing → strategia → decisione → invio ordine. Ad ogni passo c'è comunicazione inter-servizio.

2.1 gRPC Bidirectional Streaming (TCP)

gRPC è un framework Google basato su HTTP/2 che utilizza Protocol Buffers per la serializzazione. Per il trading algoritmico, lo streaming bidirezionale è particolarmente importante — quando client e server inviano simultaneamente flussi di messaggi su un'unica connessione.

Perché gRPC si adatta ai sistemi di trading:

• Protobuf è compatto (3–10 volte più piccolo di JSON)
• Multiplexing HTTP/2 — diversi stream su un'unica connessione TCP
• Tipizzazione rigorosa tramite schemi .proto che rilevano errori in fase di compilazione
• Generazione di codice per Python, Rust, Go, C++, Java, ecc.
• Lo streaming bidirezionale abilita il pattern "dati di mercato in discesa, ordini in salita" su un unico canale.

Secondo SmartDev, il 70% delle istituzioni finanziarie che implementano HFT guidato da AI utilizza gRPC o TCP grezzo per tempi di risposta in microsecondi.

Esempio di architettura: Market Data Collector (Rust) → gRPC stream → Strategy Engine (Python/Rust) → gRPC call → Order Router (Rust) → WebSocket/FIX → Exchange.

2.2 gRPC via Unix Domain Socket (UDS)

Se i servizi girano sulla stessa macchina (tipico per la co-location), TCP è un overhead inutile. Unix Domain Socket (UDS) bypassa l'intero stack di rete: nessun handshake TCP, nessun routing, nessun checksum.

I benchmark mostrano una differenza significativa:

• gRPC via UDS: ~102 μs/richiesta (100K richieste)
• gRPC via TCP: ~127 μs/richiesta (100K richieste)
• Guadagno UDS: ~20% su messaggi piccoli, fino al 50% su quelli grandi (100KB+).

Secondo F. Werner (MPI Heidelberg), confrontando gRPC UDS con I/O bloccante grezzo via UDS, gRPC aggiunge circa 10x di overhead — mediana ~130 μs vs. ~13 μs per UDS grezzo. Questo è il costo dell'astrazione (framing HTTP/2, serializzazione protobuf).

Quando usare gRPC+UDS: Comunicazione inter-processo su un singolo server quando la comodità per lo sviluppatore (schema, codegen) è valutata più della latenza minima assoluta. UDS offre anche vantaggi di sicurezza tramite i permessi dei file Unix.

Quando NON usare: Se si ha bisogno di latenza <10 μs, la memoria condivisa o UDS grezzo senza gRPC è meglio. Per riferimento: UDS grezzo mediana ~13 μs, gRPC UDS mediana ~130 μs. Memoria condivisa (Aeron IPC) è sotto 1 μs, il ring buffer LMAX Disruptor è intorno a 50–100 ns. Quindi gRPC+UDS è ~10x più lento di UDS grezzo e 100–1000x più lento della memoria condivisa. Ma ogni passo verso latenze inferiori è un passo verso una maggiore complessità del codice.

Riproducilo tu stesso: Tutti i numeri di latenza IPC in questa sezione sono riproducibili con il benchmark open-source companion suenot/trading-ipc-bench — implementazioni Python di TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory e Named Pipe round-trip, che misurano la latenza p50/p95/p99/p99.9 e il throughput sul tuo hardware.

UDS grezzo senza gRPC — se l'overhead di gRPC è eccessivo, rimuovilo e tieni solo il socket. Opzioni in ordine decrescente di prestazioni:

• Socket AF_UNIX + serializzazione personalizzata (SBE, FlatBuffers, MessagePack) — ~13 μs mediana, massimo controllo, massima complessità
• ZeroMQ IPC (ipc://) — ~50–100 μs, pattern già pronti (PUB/SUB, REQ/REP) senza boilerplate, usa UDS internamente
• nanomsg/NNG IPC — simile a ZeroMQ, latenza leggermente migliore su messaggi piccoli (<64 KB)
• Cap'n Proto RPC su UDS — serializzazione zero-copy + astrazione RPC, più veloce di gRPC, ha schema

2.3 Shared Memory IPC

Per latenza ultra-bassa sullo stesso host, usare la memoria condivisa. Due processi mappano lo stesso segmento RAM e i dati passano senza syscall (eccetto per la configurazione iniziale).

Il pattern LMAX Disruptor (ring buffer in memoria condivisa) gestisce ~6 milioni di eventi al secondo su un singolo thread. Questo approccio è il cuore di LMAX Exchange e di molti sistemi HFT.

Implementazioni: Aeron IPC (Java/C++), Chronicle Queue (Java), soluzioni personalizzate basate su mmap (Rust/C++). IronSBE (implementazione Rust di SBE) supporta la memoria condivisa IPC con latenza ~20 ns a livello di canale SPSC.

3. Sistemi di Trasporto: Message Broker e Librerie

3.1 Aeron — Lo Standard d'Oro

Aeron è un sistema di trasporto messaggi open-source ad alte prestazioni sviluppato da Real Logic. I suoi creatori sono Martin Thompson (ex CTO di LMAX) e Todd Montgomery (ex CTO di 29West). È iniziato nel 2014 per un importante exchange americano e ora conta 70+ contributor e 5000+ subscriber su GitHub.

In pratica: Aeron non è un broker (come Kafka) né una libreria socket (come ZeroMQ). È un livello di trasporto progettato per una latenza bassa e prevedibile. Funziona su UDP (rete) e memoria condivisa (IPC), fornendo consegna affidabile, ordinamento e controllo del flusso — cose che l'UDP grezzo non ha. Pensa ad Aeron come "TCP con la latenza di UDP."

Caratteristiche di Aeron:

• Latenza: <100 μs nel cloud, <18 μs su bare metal.
• Throughput: >1M messaggi/s a latenza in microsecondi.
• 20M+ messaggi/s al picco.
• Brokerless — nessun single point of failure.
• Supporta unicast, multicast e IPC.
• Controllo del flusso e rilevamento perdite integrati.

Aeron Cluster — replicazione di macchine a stati fault-tolerant (consenso Raft) per logica di trading coerente con latenza aggiuntiva minima.

Aeron Archive — persistenza dei messaggi alla piena velocità dello stream con capacità di replay.

Aeron Sequencer — il componente più recente dell'ecosistema, progettato per coordinare più progetti in grandi organizzazioni. Costruito sopra Aeron Transport e Aeron Cluster. Caratteristiche chiave:

• Log distribuito — una lunga sequenza di messaggi replicati su più macchine per la fault tolerance
• Lettori multipli — più applicazioni leggono simultaneamente dallo stesso log per scopi diversi
• Team disaccoppiati — i team rimangono indipendenti pur operando all'interno di un sistema coordinato unico
• Casi d'uso target: elaborazione dei dati di mercato, piattaforme broker, motori degli exchange

Confronto con Kafka: Entrambi usano un log distribuito, ma Aeron è per la latenza in microsecondi, mentre Kafka è per la durabilità e il throughput in millisecondi. Aeron esiste per la logica in tempo reale; Kafka per le pipeline di dati e l'analisi.

3.2 Apache Kafka

Apache Kafka è lo standard de facto per lo streaming di eventi su larga scala. Non è adatto al hot path del trade (ritardi in millisecondi) ma è indispensabile per:

• Aggregazione dei dati di mercato: raccolta di stream da 100+ exchange in un'unica pipeline.
• Event sourcing: registrazione di ogni azione del sistema come evento in un topic.
• CDC (Change Data Capture): streaming delle modifiche al DB di trading verso l'analisi.
• Integrazione QuestDB: Kafka → QuestDB per analisi tick in tempo reale.

La latenza è 2–15 ms end-to-end. Inaccettabile per HFT, ma adeguata per strategie con orizzonte >1s.

3.3 Redis Pub/Sub e Streams

Redis è un archivio in-memory che funziona anche come broker leggero.

Redis Pub/Sub — fire-and-forget; latenza sub-millisecondo. Ideale per notifiche in tempo reale: aggiornamenti dei prezzi, segnali di strategia, alert.

Redis Streams — aggiunge persistenza e consumer group (mini-Kafka). Supporta la lettura della storia e gli ACK.

Redis è più veloce di Kafka per messaggi piccoli (sub-ms), ma manca della robusta replicazione e durabilità di Kafka.

3.4 NATS

NATS è un sistema ultra-leggero scritto in Go. Latenza sub-ms, pub/sub integrato, request/reply. NATS JetStream aggiunge persistenza e consegna exactly-once.

3.5 ZeroMQ e nanomsg

Librerie brokerless che forniscono astrazioni socket per la comunicazione peer-to-peer. ZeroMQ gestisce 5M+ messaggi/s ed è battle-tested dal 2007. nanomsg (e NNG) è il suo "successore" con latenza migliore su messaggi piccoli (<64KB).

4. PUB/SUB in Tempo Reale per i Client: Centrifugo

Centrifugo è un server PUB/SUB self-hosted scritto in Go, ottimizzato per il broadcasting a migliaia/milioni di client via WebSocket, SSE o gRPC.

Perché Centrifugo per l'Algo Trading:

• Gestisce 1M connessioni WebSocket e 30M messaggi/min su un singolo server.
• Supporta lo streaming a 60Hz.
• Delta compression (algoritmo Fossil) per minimizzare il traffico.
• Perfetto per il "last mile" verso dashboard web o app mobile.

5. Archivi di Dati per l'Accesso in Tempo Reale

5.1 QuestDB — Time-Series per il Trading

QuestDB è un database time-series open-source scritto in Java (zero-GC), C++ e Rust.

• Query: Esecuzione vettorizzata sub-ms tramite SIMD.
• SAMPLE BY/ASOF JOIN: Estensioni SQL native pensate per i trader.
• WAL: Append a latenza ultra-bassa.
• Utilizzato da B3 (borsa valori brasiliana).

5.2 Redis come Data Layer

Tipicamente un livello intermedio:

• Hot cache per accesso O(1) ai prezzi.
• Sorted set per gli orderbook.
• Script Lua per operazioni atomiche.

5.3 Soluzioni Specializzate: RayforceDB, AXL DB

Database vettoriali minimalisti basati su C (binario <1MB) con zero dipendenze e accelerazione SIMD. Focus sulla latenza deterministica per HFT.

6. Serializzazione: Protobuf vs SBE vs JSON

7. Architetture di Riferimento

7.1 Crypto Arbitrage (Media Frequenza)

Exchange → Collector (Rust) → Redis (Hot) → Strategy (Python) → gRPC → Router (Rust) → Exchange.

7.2 HFT Market Making (Co-location)

Exchange Feed → Kernel Bypass NIC → Aeron IPC → Strategy (C++) → SBE → Aeron → Exchange.

8. Consigli Pratici

• <10 μs (HFT): FPGA, memoria condivisa, SBE, Aeron IPC.
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (Media Frequenza): WebSocket, Kafka, Redis.
• >10 ms (Bassa Frequenza / Swing): REST API è sufficiente. DCA, ribilanciamento, gestione del portafoglio.

Non ottimizzare ciò che non è un collo di bottiglia. Se la tua strategia impiega 50 ms per decidere, i 100 μs risparmiati da Aeron non avranno importanza. Le architetture ibride sono normali: usa REST per la configurazione, gRPC per il cuore e WS per la consegna.

Repository di Benchmark

I numeri di latenza citati in questo articolo possono essere riprodotti con suenot/trading-ipc-bench — una suite di benchmark Python open-source che copre tutti i principali trasporti IPC discussi qui: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub e Shared Memory.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # esegue tutti gli 8 trasporti, salva i risultati in results/
python report.py    # stampa una tabella riassuntiva + grafico ASCII della latenza

Eseguilo sul tuo hardware — i risultati differiranno dai numeri in questo articolo a seconda della CPU, del sistema operativo, della versione del kernel e della configurazione. Questo è il punto.

Conclusione

Non esiste una tecnologia di comunicazione "perfetta". Ogni livello ha requisiti unici: esterno (compatibilità), interno (latenza), pipeline (affidabilità) e client (flessibilità). L'architettura consiste nello scegliere lo strumento giusto per il lavoro specifico.