Datacommunicatie in Algo Trading-systemen: Een Technologie-overzicht

In algoritmische handel kan het verschil tussen winst en verlies gemeten worden in microseconden. De architectuur van datatransmissie is een van de belangrijkste factoren die de efficiëntie van een handelssysteem bepalen. In dit artikel bespreken we communicatietechnologieën op alle niveaus: van interactie met de exchange tot interne communicatie tussen services, opslag en datadistributie.

Het artikel is ingedeeld naar niveaus—van "extern" (exchange-protocollen) naar "intern" (IPC, message brokers, opslag)—wat de werkelijke architectuur van een algoritmisch handelsplatform weerspiegelt.

1. Interactie met de Exchange: REST, WebSocket, FIX

1.1 REST API

REST is de eenvoudigste en meest gebruikte manier om te communiceren met een exchange-API. Elk verzoek is een aparte HTTP-verbinding: TCP-handshake → TLS-handshake → verzoek versturen → antwoord ontvangen → verbinding sluiten.

REST-problemen voor Trading:

Elk verzoek brengt overhead met zich mee voor het opzetten van de verbinding. Zelfs met HTTP keep-alive betekent het "request-response"-model dat je geen data sneller kunt ontvangen dan je verzoeken kunt versturen. Dit leidt tot polling—een eindeloze cyclus van "is er nieuwe data?"-vragen die tot 80% van de belasting op exchange-servers veroorzaken (volgens ontwikkelaars van crypto-exchanges). Exchanges introduceren rate limits (doorgaans 10–1200 verzoeken per minuut), waardoor REST ongeschikt is voor high-frequency strategieën.

Wanneer REST geschikt is: het ophalen van historische data (candles, OHLCV), accountbeheer (saldo, posities), niet-realtime operaties (DCA-bots, uurlijkse herbalancering).

1.2 WebSocket

WebSocket brengt één persistente TCP-verbinding tot stand waardoor data bidirectioneel stroomt. Het begint als een gewoon HTTP-verzoek met een Upgrade-header en schakelt vervolgens over naar een bidirectioneel framing-protocol (payload kan tekst-JSON of binair zijn).

Voordelen voor Trading:

Het belangrijkste voordeel is dat er geen overhead per verzoek is. Zodra de verbinding is opgezet, wordt data direct door de server verstuurd. De latentie voor het leveren van marktdata via WebSocket is doorgaans minder dan 50 ms vanaf de exchange-gateway tot de client. Je kunt je tegelijkertijd abonneren op 50+ symbolen via één verbinding.

Een cruciaal punt: orders via WebSocket. Veel traders weten niet dat sommige exchanges (Binance, HitBTC, Deribit, Bybit, etc.) toestaan om orders via WebSocket te versturen, niet alleen data te ontvangen. Dit is fundamenteel sneller dan REST omdat:

• Er geen TCP/TLS-handshake nodig is voor elke order (de verbinding is al "warm")
• Er geen HTTP-overhead is (headers, cookies, etc.)
• Het een asynchroon model is: je verstuurt een order en ontvangt bevestiging via dezelfde WebSocket zonder de thread te blokkeren.

Volgens Deribit hebben WebSocket en FIX vaak dezelfde uitvoeringssnelheid. REST is iets langzamer vanwege preprocessing op verbindingsniveau. WebSocket-orders komen net als FIX-orders in de matching-engine-wachtrij terecht.

Probleem van Gemengde Context. Als je orders verstuurt via REST maar uitvoeringsmeldingen ontvangt via WebSocket, ontstaat er een race condition: de WebSocket-melding kan aankomen voordat het REST-verzoek is voltooid. Dit leidt tot inconsistentie van de status. De oplossing is om orders via dezelfde WebSocket te versturen en volledig over te stappen naar een asynchroon model.

1.3 FIX-protocol (Financial Information eXchange)

FIX is de industriestandaard voor elektronisch handelen, sinds 1992 (gecreëerd door Fidelity Investments en Salomon Brothers). Het is een binair-over-TCP-protocol dat specifiek is ontworpen voor handel.

FIX-architectuur:

• Sessielaag — beheert de verbinding, heartbeats, sequentienummering, gap-recovery. Garandeert levering en volgorde van berichten.
• Applicatielaag — bedrijfslogica: ordertypes, executierapporten, marktdataverzoeken.

FIX-berichten bestaan uit "tag=value"-paren gescheiden door een SOH-teken. Bijvoorbeeld, een koop-order voor 100 aandelen AAPL tegen $150 ziet er zo uit:

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

Waarom FIX sneller is dan WebSocket: FIX is een native TCP-protocol zonder HTTP-lagen. AWS beveelt in zijn tick-to-trade-optimalisatiegids voor crypto-exchanges expliciet FIX aan boven REST en WebSocket om door het protocol veroorzaakte latentie te minimaliseren. FIX werkt op het niveau van microseconden, terwijl WebSocket doorgaans in milliseconden werkt.

Waar FIX domineert: DMA (Direct Market Access) naar de matching-engine van de exchange, algoritmische en HFT-handel in institutionele omgevingen, liquiditeitsaggregatie (prime brokers die via FIX verbinding maken met tientallen banken).

Beperkingen van FIX: complexiteit van integratie, verouderd berichtformaat (tekstuele tag-values zijn minder efficiënt dan binaire formaten), hoge instapdrempel. In de cryptosector wordt FIX ondersteund door een beperkt aantal exchanges.

1.4 SBE (Simple Binary Encoding) — Evolutionaire FIX

SBE is een binair serialisatieformaat gecreëerd door de High Performance Working Group binnen de FIX Trading Community. De missie is om het tekstuele FIX-formaat te vervangen door een compacte binaire representatie voor ultra-lage-latentiehandel.

Belangrijkste principes van SBE:

• Zero-copy flyweight-patroon — encoders en decoders fungeren als "templates" over een buffer. Waarden worden direct geschreven zonder tussenliggende kopieën (in tegenstelling tot Protobuf, dat er meerdere vereist).
• Wire-formaat = geheugenformaat — data op de lijn ziet er precies zo uit als in het geheugen, wat de overhead van transformatie minimaliseert.
• Vaste velden eerst, variabele velden laatst — een ontwerpbeperking die een tiental keer meer prestaties oplevert vergeleken met Protocol Buffers.

SBE + Aeron is de standaardcombinatie voor high-performance handelssystemen. Aeron is een open-source messagingsysteem van Real Logic (gecreëerd door Martin Thompson, voormalig CTO van LMAX Exchange, en Todd Montgomery, voormalig CTO van 29West/Ultra Messaging). Het is in feite een gespecialiseerde transportlaag voor financiële systemen die werkt over UDP en shared memory met latenties in enkele microseconden. SBE verzorgt de serialisatie, terwijl Aeron de levering beheert met latenties van enkele microseconden. Meer over Aeron in sectie 3.1.

1.5 Vergelijkingstabel van Exchange-protocollen

2. Interne Microservicecommunicatie

Zodra data van de exchange het systeem binnenkomt, begint de interne verwerking: parsen → strategie → beslissing → order versturen. Bij elke stap is er communicatie tussen services.

2.1 gRPC Bidirectionele Streaming (TCP)

gRPC is een Google-framework gebaseerd op HTTP/2 dat Protocol Buffers gebruikt voor serialisatie. Voor algoritmisch handelen is bidirectionele streaming bijzonder belangrijk—wanneer client en server tegelijkertijd berichtenstromen versturen via één verbinding.

Waarom gRPC past bij handelssystemen:

• Protobuf is compact (3–10 keer kleiner dan JSON)
• HTTP/2-multiplexing — meerdere streams over één TCP-verbinding
• Strikte typering via .proto-schema's die fouten tijdens compilatie opvangen
• Codegeneratie voor Python, Rust, Go, C++, Java, etc.
• Bidirectionele streaming maakt het patroon "marktdata omlaag, orders omhoog" mogelijk via één kanaal.

Volgens SmartDev gebruikt 70% van de financiële instellingen die AI-gedreven HFT inzetten gRPC of raw TCP voor reactietijden in microseconden.

Architectuurvoorbeeld: 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)

Als services op dezelfde machine draaien (typisch voor co-locatie), is TCP onnodige overhead. Unix Domain Socket (UDS) omzeilt de hele netwerkstack: geen TCP-handshake, geen routering, geen checksumberekening.

Benchmarks tonen een significant verschil:

• gRPC via UDS: ~102 μs/verzoek (100K verzoeken)
• gRPC via TCP: ~127 μs/verzoek (100K verzoeken)
• UDS-winst: ~20% bij kleine berichten, tot 50% bij grote berichten (100KB+).

Volgens F. Werner (MPI Heidelberg), die gRPC UDS vergelijkt met raw blocking I/O via UDS, voegt gRPC ongeveer 10x overhead toe—mediaan ~130 μs versus ~13 μs voor raw UDS. Dit is de prijs van abstractie (HTTP/2-framing, protobuf-serialisatie).

Wanneer gRPC+UDS gebruiken: Interprocescommunicatie op één server wanneer het gemak voor ontwikkelaars (schema, codegen) belangrijker is dan absolute minimale latentie. UDS biedt ook beveiligingsvoordelen via Unix-bestandsrechten.

Wanneer NIET te gebruiken: Als je latentie <10 μs nodig hebt, zijn shared memory of raw UDS zonder gRPC beter. Ter referentie: raw UDS mediaan ~13 μs, gRPC UDS mediaan ~130 μs. Shared memory (Aeron IPC) ligt onder 1 μs, LMAX Disruptor ring buffer ligt rond 50–100 ns. Dus gRPC+UDS is ~10x langzamer dan raw UDS en 100–1000x langzamer dan shared memory. Maar elke stap omlaag in latentie is een stap omhoog in codecomplexiteit.

Reproduceer het zelf: Alle IPC-latentiegetallen in deze sectie zijn reproduceerbaar met de open-source begeleidende benchmark suenot/trading-ipc-bench — Python-implementaties van TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory en Named Pipe round-trips, die p50/p95/p99/p99.9-latentie en doorvoer meten op je eigen hardware.

Raw UDS zonder gRPC — als de overhead van gRPC te veel is, verwijder deze en behoud alleen de socket. Opties in aflopende prestatievolgorde:

• AF_UNIX sockets + custom serialisatie (SBE, FlatBuffers, MessagePack) — ~13 μs mediaan, maximale controle, maximale complexiteit
• ZeroMQ IPC (ipc://) — ~50–100 μs, kant-en-klare patronen (PUB/SUB, REQ/REP) zonder boilerplate, gebruikt UDS onder de motorkap
• nanomsg/NNG IPC — vergelijkbaar met ZeroMQ, iets betere latentie bij kleine berichten (<64 KB)
• Cap'n Proto RPC via UDS — zero-copy serialisatie + RPC-abstractie, sneller dan gRPC, heeft een schema

2.3 Shared Memory IPC

Voor ultra-lage-latentie op dezelfde host gebruik je shared memory. Twee processen mappen hetzelfde RAM-segment, en data gaat door zonder syscalls (behalve bij de initiële setup).

Het LMAX Disruptor-patroon (ring buffer in shared memory) verwerkt ~6 miljoen events per seconde op één enkele thread. Deze aanpak vormt het hart van LMAX Exchange en veel HFT-systemen.

Implementaties: Aeron IPC (Java/C++), Chronicle Queue (Java), custom mmap-gebaseerde oplossingen (Rust/C++). IronSBE (Rust SBE-implementatie) ondersteunt shared memory IPC met ~20 ns latentie op SPSC-kanaalniveau.

3. Transportsystemen: Message Brokers en Bibliotheken

3.1 Aeron — De Gouden Standaard

Aeron is een open-source high-performance messagetransportsysteem ontwikkeld door Real Logic. De makers zijn Martin Thompson (voormalig LMAX-CTO) en Todd Montgomery (voormalig 29West-CTO). Het begon in 2014 voor een grote Amerikaanse exchange en heeft nu 70+ bijdragers en 5000+ GitHub-abonnees.

In de praktijk: Aeron is geen broker (zoals Kafka) en geen socketbibliotheek (zoals ZeroMQ). Het is een transportlaag ontworpen voor voorspelbare lage latentie. Het werkt over UDP (netwerk) en shared memory (IPC), en biedt betrouwbare levering, ordening en flow control—dingen die raw UDP mist. Zie Aeron als "TCP met UDP-latentie."

Kenmerken van Aeron:

• Latentie: <100 μs in de cloud, <18 μs op bare metal.
• Doorvoer: >1M berichten/s bij latentie in microseconden.
• 20M+ berichten/s piek.
• Brokerless — geen single point of failure.
• Ondersteunt unicast, multicast en IPC.
• Ingebouwde flow control en verliesdetectie.

Aeron Cluster — fouttolerante replicatie van state machines (Raft-consensus) voor consistente handelslogica met minimale extra latentie.

Aeron Archive — berichtpersistentie op volledige streamsnelheid met replaymogelijkheid.

Aeron Sequencer — het nieuwste onderdeel van het ecosysteem, ontworpen om meerdere projecten binnen grote organisaties te coördineren. Gebouwd bovenop Aeron Transport en Aeron Cluster. Belangrijkste kenmerken:

• Gedistribueerd logboek — een lange reeks berichten die over meerdere machines wordt gerepliceerd voor fouttolerantie
• Meerdere lezers — meerdere applicaties lezen tegelijkertijd uit hetzelfde logboek voor verschillende doeleinden
• Ontkoppelde teams — teams blijven onafhankelijk terwijl ze binnen één gecoördineerd systeem opereren
• Doelgebruiksscenario's: verwerking van marktdata, brokerplatforms, exchange-engines

Vergelijking met Kafka: Beide gebruiken een gedistribueerd logboek, maar Aeron is voor latentie in microseconden, terwijl Kafka is voor duurzaamheid en doorvoer in milliseconden. Aeron bestaat voor realtime logica; Kafka voor datapipelines en analyse.

3.2 Apache Kafka

Apache Kafka is de facto standaard voor event streaming op schaal. Het is niet voor het hot path van de handel (vertragingen in milliseconden) maar onmisbaar voor:

• Marktdata-aggregatie: het verzamelen van streams van 100+ exchanges in één pipeline.
• Event sourcing: het vastleggen van elke systeemactie als een event-topic.
• CDC (Change Data Capture): het streamen van wijzigingen in de handelsdatabase naar analytics.
• QuestDB-integratie: Kafka → QuestDB voor realtime tick-analytics.

De latentie is 2–15 ms end-to-end. Onacceptabel voor HFT, maar prima voor strategieën met een horizon van >1s.

3.3 Redis Pub/Sub en Streams

Redis is een in-memory store die ook als lichtgewicht broker werkt.

Redis Pub/Sub — fire-and-forget; sub-milliseconde latentie. Ideaal voor realtime meldingen: prijsupdates, strategiesignalen, waarschuwingen.

Redis Streams — voegt persistentie en consumergroepen toe (mini-Kafka). Ondersteunt het lezen van geschiedenis en ACKs.

Redis is sneller dan Kafka bij kleine berichten (sub-ms), maar mist de zware replicatie en duurzaamheid van Kafka.

3.4 NATS

NATS is een ultra-lichtgewicht systeem in Go. Sub-ms latentie, ingebouwde pub/sub, request/reply. NATS JetStream voegt persistentie en exactly-once delivery toe.

3.5 ZeroMQ en nanomsg

Brokerless bibliotheken die socketabstracties bieden voor peer-to-peer communicatie. ZeroMQ verwerkt 5M+ berichten/s en is sinds 2007 uitgebreid in de praktijk getest. nanomsg (en NNG) is de "opvolger" ervan met betere latentie bij kleine berichten (<64KB).

4. Realtime PUB/SUB voor Clients: Centrifugo

Centrifugo is een self-hosted PUB/SUB-server in Go, geoptimaliseerd voor het uitzenden naar duizenden/miljoenen clients via WebSocket, SSE of gRPC.

Waarom Centrifugo voor Algo Trading:

• Verwerkt 1M WebSocket-verbindingen en 30M berichten/min op één server.
• Ondersteunt 60Hz-streaming.
• Delta-compressie (Fossil-algoritme) om verkeer te minimaliseren.
• Perfect voor de "last mile" naar webdashboards of mobiele apps.

5. Realtime Toegangsdataopslag

5.1 QuestDB — Time-Series voor Trading

QuestDB is een open-source time-series database geschreven in Java (zero-GC), C++ en Rust.

• Queries: Sub-ms gevectoriseerde uitvoering via SIMD.
• SAMPLE BY/ASOF JOIN: Native trader-vriendelijke SQL-uitbreidingen.
• WAL: Ultra-lage-latentie append.
• Gebruikt door B3 (de Braziliaanse effectenbeurs).

5.2 Redis als Datalaag

Doorgaans een tussenlaag:

• Hot cache voor O(1) prijstoegang.
• Sorted sets voor orderboeken.
• Lua-scripts voor atomaire operaties.

5.3 Gespecialiseerde Oplossingen: RayforceDB, AXL DB

Minimalistische, op C gebaseerde vectordatabases (binary <1MB) zonder dependencies en met SIMD-versnelling. Gericht op deterministische latentie voor HFT.

6. Serialisatie: Protobuf vs SBE vs JSON

7. Referentiearchitecturen

7.1 Crypto Arbitrage (Gemiddelde Frequentie)

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

7.2 HFT Market Making (Co-locatie)

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

8. Praktisch Advies

• <10 μs (HFT): FPGA, shared memory, SBE, Aeron IPC.
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (Gemiddelde Frequentie): WebSocket, Kafka, Redis.
• >10 ms (Lage Frequentie / Swing): REST API is voldoende. DCA, herbalancering, portefeuillebeheer.

Optimaliseer niet wat geen bottleneck is. Als je strategie 50 ms nodig heeft om te beslissen, doen de 100 μs winst van Aeron er niet toe. Hybride architecturen zijn normaal: gebruik REST voor setup, gRPC voor het hart, en WS voor levering.

Benchmark Repository

De latentiegetallen die in dit artikel worden aangehaald, kunnen worden gereproduceerd met suenot/trading-ipc-bench — een open-source Python-benchmarksuite die alle belangrijke IPC-transporten omvat die hier worden besproken: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub en Shared Memory.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # runs all 8 transports, saves results to results/
python report.py    # prints a summary table + ASCII latency chart

Voer het uit op je eigen hardware — de resultaten zullen afwijken van de cijfers in dit artikel, afhankelijk van je CPU, besturingssysteem, kernelversie en tuning. Dat is precies de bedoeling.

Conclusie

Er bestaat geen "perfecte" communicatietechnologie. Elk niveau heeft unieke vereisten: extern (compatibiliteit), intern (latentie), pipeline (betrouwbaarheid) en client (flexibiliteit). Architectuur draait om het kiezen van het juiste gereedschap voor de specifieke taak.