Datenkommunikation in Algo-Trading-Systemen: Ein Technologieüberblick

Im algorithmischen Handel lässt sich der Unterschied zwischen Gewinn und Verlust in Mikrosekunden messen. Die Architektur der Datenübertragung ist einer der Schlüsselfaktoren, die die Effizienz eines Handelssystems bestimmen. In diesem Artikel gehen wir die Kommunikationstechnologien auf allen Ebenen durch: von der Interaktion mit der Börse bis zur internen Kommunikation zwischen Diensten, Speicherung und Datenverteilung.

Der Artikel ist nach Ebenen gegliedert – von "extern" (Börsenprotokolle) bis "intern" (IPC, Message-Broker, Speicherung) – und spiegelt damit die reale Architektur einer algorithmischen Handelsplattform wider.

1. Interaktion mit der Börse: REST, WebSocket, FIX

1.1 REST API

REST ist die einfachste und gebräuchlichste Art, mit einer Börsen-API zu interagieren. Jede Anfrage ist eine eigene HTTP-Verbindung: TCP-Handshake → TLS-Handshake → Anfrage senden → Antwort empfangen → Verbindung schließen.

REST-Probleme für den Handel:

Jede Anfrage bringt Overhead durch den Verbindungsaufbau mit sich. Selbst mit HTTP-Keep-Alive bedeutet das "Anfrage-Antwort"-Modell, dass man nicht schneller Daten empfangen kann, als man Anfragen sendet. Das führt zu Polling – einem endlosen Zyklus von "gibt es neue Daten?"-Anfragen, die laut Entwicklern von Krypto-Börsen bis zu 80 % der Last auf Börsenservern erzeugen. Börsen führen Rate-Limits ein (typischerweise 10–1200 Anfragen pro Minute), was REST für hochfrequente Strategien ungeeignet macht.

Wann REST angemessen ist: Abruf historischer Daten (Kerzen, OHLCV), Kontoverwaltung (Guthaben, Positionen), Operationen ohne Echtzeitanforderung (DCA-Bots, stündliches Rebalancing).

1.2 WebSocket

WebSocket baut eine einzige dauerhafte TCP-Verbindung auf, über die Daten bidirektional fließen. Es beginnt als gewöhnliche HTTP-Anfrage mit einem Upgrade-Header und wechselt dann zu einem bidirektionalen Framing-Protokoll (die Payload kann Text-JSON oder binär sein).

Vorteile für den Handel:

Der Hauptvorteil ist kein Overhead pro Anfrage. Sobald die Verbindung steht, werden Daten sofort vom Server gepusht. Die Latenz der Marktdatenzustellung über WebSocket liegt typischerweise unter 50 ms vom Börsen-Gateway bis zum Client. Man kann über eine einzige Verbindung gleichzeitig 50+ Symbole abonnieren.

Ein entscheidender Punkt: Orders über WebSocket. Viele Trader wissen nicht, dass einige Börsen (Binance, HitBTC, Deribit, Bybit usw.) erlauben, Orders über WebSocket zu senden, nicht nur Daten zu empfangen. Das ist grundsätzlich schneller als REST, weil:

• Kein TCP/TLS-Handshake für jede Order (die Verbindung ist bereits "warm")
• Kein HTTP-Overhead (Header, Cookies usw.)
• Asynchrones Modell: man sendet eine Order und erhält die Bestätigung über dieselbe WebSocket-Verbindung, ohne den Thread zu blockieren.

Laut Deribit haben WebSocket und FIX oft dieselbe Ausführungsgeschwindigkeit. REST ist aufgrund von Vorverarbeitung auf Verbindungsebene etwas langsamer. WebSocket-Orders landen genau wie FIX-Orders in der Warteschlange der Matching-Engine.

Das Problem der Kontextvermischung. Wenn man Orders über REST sendet, aber Ausführungsbenachrichtigungen über WebSocket empfängt, entsteht eine Race Condition: Die WebSocket-Benachrichtigung kann eintreffen, bevor die REST-Anfrage abgeschlossen ist. Das führt zu Zustandsinkonsistenz. Die Lösung besteht darin, Orders über dieselbe WebSocket-Verbindung zu senden und vollständig zu einem asynchronen Modell überzugehen.

1.3 FIX-Protokoll (Financial Information eXchange)

FIX ist der Industriestandard für den elektronischen Handel und existiert seit 1992 (entwickelt von Fidelity Investments und Salomon Brothers). Es ist ein binäres Protokoll über TCP, das speziell für den Handel konzipiert wurde.

FIX-Architektur:

• Session-Schicht — verwaltet Verbindung, Heartbeats, Sequenznummerierung, Lückenwiederherstellung. Garantiert Zustellung und Reihenfolge der Nachrichten.
• Anwendungsschicht — Geschäftslogik: Ordertypen, Ausführungsberichte, Marktdatenanfragen.

FIX-Nachrichten bestehen aus "tag=value"-Paaren, getrennt durch ein SOH-Zeichen. Zum Beispiel sieht eine Kauforder über 100 Aktien AAPL zu 150 $ so aus:

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

Warum FIX schneller ist als WebSocket: FIX ist ein natives TCP-Protokoll ohne HTTP-Schichten. AWS empfiehlt in seinem Tick-to-Trade-Optimierungsleitfaden für Krypto-Börsen ausdrücklich FIX gegenüber REST und WebSocket, um protokollbedingte Latenz zu minimieren. FIX arbeitet auf Mikrosekundenebene, während WebSocket typischerweise im Millisekundenbereich liegt.

Wo FIX dominiert: DMA (Direct Market Access) zur Matching-Engine der Börse, algorithmischer und HFT-Handel im institutionellen Bereich, Liquiditätsaggregation (Prime Broker, die sich über FIX mit Dutzenden von Banken verbinden).

Einschränkungen von FIX: Komplexität der Integration, veraltetes Nachrichtenformat (textbasierte Tag-Value-Paare sind weniger effizient als Binärformate), hohe Einstiegshürde. In der Krypto-Branche wird FIX nur von einer begrenzten Anzahl von Börsen unterstützt.

1.4 SBE (Simple Binary Encoding) — Die Weiterentwicklung von FIX

SBE ist ein binäres Serialisierungsformat, das von der High Performance Working Group innerhalb der FIX Trading Community entwickelt wurde. Seine Mission ist es, das textbasierte FIX-Format durch eine kompakte binäre Darstellung für Handel mit ultraniedriger Latenz zu ersetzen.

Kernprinzipien von SBE:

• Zero-Copy-Flyweight-Muster — Encoder und Decoder agieren als "Vorlagen" über einem Puffer. Werte werden direkt geschrieben, ohne Zwischenkopien (im Gegensatz zu Protobuf, das mehrere benötigt).
• Wire-Format = Speicherformat — Daten auf der Leitung sehen genauso aus wie im Speicher, was den Transformations-Overhead minimiert.
• Feste Felder zuerst, variable Felder zuletzt — eine Designbeschränkung, die eine um eine Größenordnung höhere Leistung im Vergleich zu Protocol Buffers liefert.

SBE + Aeron ist die Standardkombination für Hochleistungs-Handelssysteme. Aeron ist ein Open-Source-Messaging-System von Real Logic (entwickelt von Martin Thompson, ehemaliger CTO von LMAX Exchange, und Todd Montgomery, ehemaliger CTO von 29West/Ultra Messaging). Es ist im Wesentlichen eine spezialisierte Transportschicht für Finanzsysteme, die über UDP und Shared Memory mit Latenzen im einstelligen Mikrosekundenbereich arbeitet. SBE übernimmt die Serialisierung, während Aeron die Zustellung mit Mikrosekundenverzögerungen verwaltet. Mehr zu Aeron in Abschnitt 3.1.

1.5 Vergleichstabelle der Börsenprotokolle

2. Interne Kommunikation zwischen Microservices

Sobald Daten von der Börse in das System gelangen, beginnt die interne Verarbeitung: Parsing → Strategie → Entscheidung → Order senden. Bei jedem Schritt findet Kommunikation zwischen Diensten statt.

2.1 gRPC Bidirektionales Streaming (TCP)

gRPC ist ein Google-Framework, das auf HTTP/2 basiert und Protocol Buffers zur Serialisierung verwendet. Für algorithmischen Handel ist besonders bidirektionales Streaming wichtig — wenn Client und Server gleichzeitig Nachrichtenströme über eine einzige Verbindung senden.

Warum gRPC zu Handelssystemen passt:

• Protobuf ist kompakt (3–10-mal kleiner als JSON)
• HTTP/2-Multiplexing — mehrere Streams über eine TCP-Verbindung
• Strikte Typisierung über .proto-Schemas, die Fehler zur Kompilierzeit abfängt
• Codegenerierung für Python, Rust, Go, C++, Java usw.
• Bidirektionales Streaming ermöglicht das Muster "Marktdaten runter, Orders rauf" über einen einzigen Kanal.

Laut SmartDev nutzen 70 % der Finanzinstitute, die KI-gesteuertes HFT einsetzen, gRPC oder rohes TCP für Antwortzeiten im Mikrosekundenbereich.

Architekturbeispiel: Market Data Collector (Rust) → gRPC-Stream → Strategy Engine (Python/Rust) → gRPC-Aufruf → Order Router (Rust) → WebSocket/FIX → Börse.

2.2 gRPC über Unix Domain Socket (UDS)

Wenn Dienste auf derselben Maschine laufen (typisch für Co-Location), ist TCP unnötiger Overhead. Unix Domain Socket (UDS) umgeht den gesamten Netzwerk-Stack: kein TCP-Handshake, kein Routing, keine Prüfsummenbildung.

Benchmarks zeigen einen erheblichen Unterschied:

• gRPC über UDS: ~102 μs/Anfrage (100K Anfragen)
• gRPC über TCP: ~127 μs/Anfrage (100K Anfragen)
• UDS-Gewinn: ~20 % bei kleinen Nachrichten, bis zu 50 % bei großen (100 KB+).

Laut F. Werner (MPI Heidelberg), der gRPC UDS mit rohem blockierendem I/O über UDS verglichen hat, fügt gRPC etwa das 10-fache an Overhead hinzu — Median ~130 μs gegenüber ~13 μs für rohes UDS. Das ist der Preis der Abstraktion (HTTP/2-Framing, Protobuf-Serialisierung).

Wann gRPC+UDS verwenden: Interprozesskommunikation auf einem einzigen Server, wenn Entwicklerkomfort (Schema, Codegen) wichtiger ist als absolut minimale Latenz. UDS bietet zudem Sicherheitsvorteile über Unix-Dateiberechtigungen.

Wann NICHT verwenden: Wenn eine Latenz <10 μs erforderlich ist, sind Shared Memory oder rohes UDS ohne gRPC besser. Zum Vergleich: rohes UDS Median ~13 μs, gRPC UDS Median ~130 μs. Shared Memory (Aeron IPC) liegt unter 1 μs, der LMAX Disruptor-Ringpuffer liegt bei etwa 50–100 ns. Somit ist gRPC+UDS ~10-mal langsamer als rohes UDS und 100–1000-mal langsamer als Shared Memory. Aber jeder Schritt hinunter in der Latenz ist ein Schritt hinauf in der Codekomplexität.

Reproduzieren Sie es selbst: Alle IPC-Latenzzahlen in diesem Abschnitt sind mit der Open-Source-Begleit-Benchmark suenot/trading-ipc-bench reproduzierbar — Python-Implementierungen von Round-Trips über TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory und Named Pipe, die p50/p95/p99/p99.9-Latenz und Durchsatz auf Ihrer eigenen Hardware messen.

Rohes UDS ohne gRPC — wenn der gRPC-Overhead zu hoch ist, entfernen Sie ihn und behalten nur den Socket. Optionen nach absteigender Leistung:

• AF_UNIX-Sockets + eigene Serialisierung (SBE, FlatBuffers, MessagePack) — ~13 μs Median, maximale Kontrolle, maximale Komplexität
• ZeroMQ IPC (ipc://) — ~50–100 μs, fertige Muster (PUB/SUB, REQ/REP) ohne Boilerplate, nutzt intern UDS
• nanomsg/NNG IPC — ähnlich wie ZeroMQ, etwas bessere Latenz bei kleinen Nachrichten (<64 KB)
• Cap'n Proto RPC über UDS — Zero-Copy-Serialisierung + RPC-Abstraktion, schneller als gRPC, mit Schema

2.3 Shared-Memory-IPC

Für ultraniedrige Latenz auf demselben Host verwendet man Shared Memory. Zwei Prozesse mappen dasselbe RAM-Segment, und Daten werden ohne Syscalls übertragen (außer beim initialen Setup).

Das LMAX-Disruptor-Muster (Ringpuffer im Shared Memory) verarbeitet ~6 Millionen Ereignisse pro Sekunde auf einem einzigen Thread. Dieser Ansatz ist das Herzstück von LMAX Exchange und vielen HFT-Systemen.

Implementierungen: Aeron IPC (Java/C++), Chronicle Queue (Java), eigene mmap-basierte Lösungen (Rust/C++). IronSBE (eine Rust-SBE-Implementierung) unterstützt Shared-Memory-IPC mit ~20 ns Latenz auf Ebene des SPSC-Kanals.

3. Transportsysteme: Message-Broker und -Bibliotheken

3.1 Aeron — Der Goldstandard

Aeron ist ein Open-Source-Hochleistungs-Nachrichtentransportsystem, entwickelt von Real Logic. Seine Schöpfer sind Martin Thompson (ehemaliger LMAX-CTO) und Todd Montgomery (ehemaliger 29West-CTO). Es begann 2014 für eine große US-Börse und hat inzwischen 70+ Mitwirkende und 5000+ GitHub-Abonnenten.

In der Praxis: Aeron ist weder ein Broker (wie Kafka) noch eine Socket-Bibliothek (wie ZeroMQ). Es ist eine Transportschicht, die für vorhersagbare niedrige Latenz konzipiert wurde. Es funktioniert über UDP (Netzwerk) und Shared Memory (IPC) und bietet zuverlässige Zustellung, Reihenfolge und Flusskontrolle — Dinge, die rohem UDP fehlen. Man kann sich Aeron als "TCP mit UDP-Latenz" vorstellen.

Eigenschaften von Aeron:

• Latenz: <100 μs in der Cloud, <18 μs auf Bare Metal.
• Durchsatz: >1 Mio. Nachrichten/s bei Mikrosekunden-Latenz.
• Spitzenwert 20 Mio.+ Nachrichten/s.
• Brokerless — kein Single Point of Failure.
• Unterstützt Unicast, Multicast und IPC.
• Eingebaute Flusskontrolle und Verlusterkennung.

Aeron Cluster — fehlertolerante Zustandsmaschinenreplikation (Raft-Konsens) für konsistente Handelslogik mit minimal zusätzlicher Latenz.

Aeron Archive — Nachrichtenpersistenz bei voller Stream-Geschwindigkeit mit Wiedergabefunktion.

Aeron Sequencer — die neueste Komponente des Ökosystems, konzipiert zur Koordination mehrerer Projekte über große Organisationen hinweg. Aufgebaut auf Aeron Transport und Aeron Cluster. Wichtige Eigenschaften:

• Verteiltes Log — eine lange Sequenz von Nachrichten, die über mehrere Maschinen repliziert wird, zur Fehlertoleranz
• Mehrere Leser — mehrere Anwendungen lesen gleichzeitig aus demselben Log für unterschiedliche Zwecke
• Entkoppelte Teams — Teams bleiben unabhängig, während sie innerhalb eines einzigen koordinierten Systems arbeiten
• Ziel-Anwendungsfälle: Marktdatenverarbeitung, Broker-Plattformen, Börsen-Engines

Vergleich mit Kafka: Beide nutzen ein verteiltes Log, aber Aeron ist für Mikrosekunden-Latenz gedacht, während Kafka für Millisekunden-Haltbarkeit und -Durchsatz steht. Aeron existiert für Echtzeitlogik; Kafka für Datenpipelines und Analytik.

3.2 Apache Kafka

Apache Kafka ist der De-facto-Standard für Event-Streaming im großen Maßstab. Es ist nichts für den heißen Handelspfad (Millisekundenverzögerungen), aber unverzichtbar für:

• Marktdatenaggregation: Sammlung von Streams von 100+ Börsen in einer Pipeline.
• Event Sourcing: Aufzeichnung jeder Systemaktion als Ereignis-Topic.
• CDC (Change Data Capture): Streaming von Änderungen der Handels-DB zur Analytik.
• QuestDB-Integration: Kafka → QuestDB für Echtzeit-Tick-Analytik.

Die Latenz beträgt 2–15 ms End-to-End. Für HFT inakzeptabel, aber gut geeignet für Strategien mit einem Horizont von >1 s.

3.3 Redis Pub/Sub und Streams

Redis ist ein In-Memory-Speicher, der auch als leichtgewichtiger Broker funktioniert.

Redis Pub/Sub — Fire-and-Forget; Latenz unter einer Millisekunde. Ideal für Echtzeitbenachrichtigungen: Preisaktualisierungen, Strategiesignale, Alerts.

Redis Streams — fügt Persistenz und Consumer-Gruppen hinzu (Mini-Kafka). Unterstützt das Lesen der Historie und ACKs.

Redis ist bei kleinen Nachrichten schneller als Kafka (unter einer Millisekunde), verfügt aber nicht über Kafkas robuste Replikation und Haltbarkeit.

3.4 NATS

NATS ist ein ultraleichtes System in Go. Latenz unter einer Millisekunde, eingebautes Pub/Sub, Request/Reply. NATS JetStream fügt Persistenz und Exactly-Once-Zustellung hinzu.

3.5 ZeroMQ und nanomsg

Brokerless-Bibliotheken, die Socket-Abstraktionen für Peer-to-Peer-Kommunikation bieten. ZeroMQ verarbeitet 5 Mio.+ Nachrichten/s und ist seit 2007 im produktiven Einsatz erprobt. nanomsg (und NNG) ist sein "Nachfolger" mit besserer Latenz bei kleinen Nachrichten (<64 KB).

4. Echtzeit-PUB/SUB für Clients: Centrifugo

Centrifugo ist ein selbst gehosteter PUB/SUB-Server in Go, optimiert für die Übertragung an Tausende/Millionen von Clients über WebSocket, SSE oder gRPC.

Warum Centrifugo für Algo-Trading:

• Verarbeitet 1 Mio. WebSocket-Verbindungen und 30 Mio. Nachrichten/Min auf einem einzigen Server.
• Unterstützt 60-Hz-Streaming.
• Delta-Kompression (Fossil-Algorithmus) zur Minimierung des Traffics.
• Perfekt für die "letzte Meile" zu Web-Dashboards oder mobilen Apps.

5. Datenspeicher mit Echtzeitzugriff

5.1 QuestDB — Zeitreihen für den Handel

QuestDB ist eine Open-Source-Zeitreihendatenbank, geschrieben in Java (zero-GC), C++ und Rust.

• Abfragen: Vektorisierte Ausführung unter einer Millisekunde mittels SIMD.
• SAMPLE BY/ASOF JOIN: Native, traderfreundliche SQL-Erweiterungen.
• WAL: Anhängen mit ultraniedriger Latenz.
• Wird von B3 (der brasilianischen Börse) genutzt.

5.2 Redis als Datenschicht

Typischerweise eine Zwischenschicht:

• Hot Cache für O(1)-Preiszugriff.
• Sorted Sets für Orderbücher.
• Lua-Skripte für atomare Operationen.

5.3 Spezialisierte Lösungen: RayforceDB, AXL DB

Minimalistische, C-basierte Vektordatenbanken (Binärgröße <1 MB) ohne Abhängigkeiten und mit SIMD-Beschleunigung. Fokus auf deterministische Latenz für HFT.

6. Serialisierung: Protobuf vs. SBE vs. JSON

7. Referenzarchitekturen

7.1 Krypto-Arbitrage (mittlere Frequenz)

Börsen → Collector (Rust) → Redis (Hot) → Strategie (Python) → gRPC → Router (Rust) → Börse.

7.2 HFT-Market-Making (Co-Location)

Börsenfeed → Kernel-Bypass-NIC → Aeron IPC → Strategie (C++) → SBE → Aeron → Börse.

8. Praktische Ratschläge

• <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 (mittlere Frequenz): WebSocket, Kafka, Redis.
• >10 ms (niedrige Frequenz / Swing): REST-API ist ausreichend. DCA, Rebalancing, Portfoliomanagement.

Optimieren Sie nicht, was kein Engpass ist. Wenn Ihre Strategie 50 ms für eine Entscheidung braucht, spielt die Ersparnis von 100 μs durch Aeron keine Rolle. Hybride Architekturen sind normal: REST für die Einrichtung, gRPC als Herzstück und WS für die Zustellung.

Benchmark-Repository

Die in diesem Artikel zitierten Latenzzahlen lassen sich mit suenot/trading-ipc-bench reproduzieren — einer Open-Source-Python-Benchmark-Suite, die alle hier besprochenen wichtigen IPC-Transporte abdeckt: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub und 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

Führen Sie es auf Ihrer eigenen Hardware aus — die Ergebnisse werden je nach CPU, Betriebssystem, Kernel-Version und Tuning von den Zahlen in diesem Artikel abweichen. Genau darum geht es.

Fazit

Es gibt keine "perfekte" Kommunikationstechnologie. Jede Ebene hat eigene Anforderungen: extern (Kompatibilität), intern (Latenz), Pipeline (Zuverlässigkeit) und Client (Flexibilität). Architektur bedeutet, für die jeweilige Aufgabe das richtige Werkzeug zu wählen.