Komunikasi Data dalam Sistem Algo Trading: Tinjauan Teknologi

Dalam algorithmic trading, perbedaan antara untung dan rugi bisa diukur dalam mikrodetik. Arsitektur transmisi data adalah salah satu faktor kunci yang menentukan efisiensi sebuah sistem trading. Dalam artikel ini, kita akan menguraikan teknologi komunikasi di semua level: mulai dari berinteraksi dengan bursa hingga komunikasi antar-layanan internal, penyimpanan, dan distribusi data.

Artikel ini disusun berdasarkan level—dari "eksternal" (protokol bursa) hingga "internal" (IPC, message broker, penyimpanan)—mencerminkan arsitektur nyata sebuah platform algorithmic trading.

1. Interaksi dengan Bursa: REST, WebSocket, FIX

1.1 REST API

REST adalah cara paling mudah dan umum untuk berinteraksi dengan API bursa. Setiap permintaan adalah koneksi HTTP terpisah: TCP handshake → TLS handshake → kirim permintaan → terima respons → tutup koneksi.

Masalah REST untuk Trading:

Setiap permintaan membawa overhead penyiapan koneksi. Bahkan dengan HTTP keep-alive, model "request-response" berarti Anda tidak dapat menerima data lebih cepat daripada Anda mengirim permintaan. Hal ini menyebabkan polling—siklus tak berujung dari kueri "ada data baru?" yang menciptakan hingga 80% beban di server bursa (menurut pengembang bursa kripto). Bursa menerapkan rate limit (biasanya 10–1200 permintaan per menit), membuat REST tidak cocok untuk strategi frekuensi tinggi.

Kapan REST tepat digunakan: mengambil data historis (candle, OHLCV), manajemen akun (saldo, posisi), operasi non-real-time (bot DCA, rebalancing per jam).

1.2 WebSocket

WebSocket membuat satu koneksi TCP persisten yang memungkinkan data mengalir secara dua arah. Dimulai sebagai permintaan HTTP biasa dengan header Upgrade, kemudian beralih ke protokol framing dua arah (payload bisa berupa JSON teks atau biner).

Keunggulan untuk Trading:

Keunggulan utamanya adalah tidak ada overhead per permintaan. Setelah terhubung, data langsung dikirim oleh server. Latensi pengiriman data pasar via WebSocket biasanya kurang dari 50 ms dari gateway bursa ke klien. Anda dapat berlangganan 50+ simbol sekaligus melalui satu koneksi.

Poin kritis: order via WebSocket. Banyak trader tidak tahu bahwa beberapa bursa (Binance, HitBTC, Deribit, Bybit, dll.) mengizinkan pengiriman order via WebSocket, bukan hanya menerima data. Ini secara fundamental lebih cepat dari REST karena:

• Tidak ada TCP/TLS handshake untuk setiap order (koneksi sudah "hangat")
• Tidak ada overhead HTTP (header, cookie, dll.)
• Model asinkron: Anda mengirim order dan menerima konfirmasi melalui WebSocket yang sama tanpa memblokir thread.

Menurut Deribit, WebSocket dan FIX sering memiliki kecepatan eksekusi yang sama. REST sedikit lebih lambat karena preprocessing di level koneksi. Order WebSocket masuk ke antrian matching engine seperti order FIX.

Masalah Pencampuran Konteks. Jika Anda mengirim order via REST tetapi menerima notifikasi eksekusi via WebSocket, terjadi race condition: notifikasi WebSocket mungkin tiba sebelum permintaan REST selesai. Hal ini menyebabkan inkonsistensi status. Solusinya adalah mengirim order melalui WebSocket yang sama, beralih sepenuhnya ke model asinkron.

1.3 Protokol FIX (Financial Information eXchange)

FIX adalah standar industri untuk trading elektronik, ada sejak 1992 (dibuat oleh Fidelity Investments dan Salomon Brothers). Ini adalah protokol binary-over-TCP yang dirancang khusus untuk trading.

Arsitektur FIX:

• Session layer — mengelola koneksi, heartbeat, penomoran urutan, pemulihan gap. Menjamin pengiriman dan urutan pesan.
• Application layer — logika bisnis: tipe order, laporan eksekusi, permintaan data pasar.

Pesan FIX terdiri dari pasangan "tag=value" yang dipisahkan oleh karakter SOH. Misalnya, order beli 100 saham AAPL seharga $150 terlihat seperti ini:

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

Mengapa FIX lebih cepat dari WebSocket: FIX adalah protokol TCP native tanpa layer HTTP. AWS, dalam panduan optimasi tick-to-trade untuk bursa kripto, secara eksplisit merekomendasikan FIX daripada REST dan WebSocket untuk meminimalkan latensi yang disebabkan protokol. FIX beroperasi pada level mikrodetik, sedangkan WebSocket biasanya dalam milidetik.

Di mana FIX mendominasi: DMA (Direct Market Access) ke matching engine bursa, trading algoritmik dan HFT di institusional, agregasi likuiditas (prime broker yang terhubung ke puluhan bank via FIX).

Keterbatasan FIX: kompleksitas integrasi, format pesan yang sudah tua (tag-value tekstual kurang efisien dibandingkan format biner), hambatan masuk yang tinggi. Di industri kripto, FIX hanya didukung oleh sejumlah kecil bursa.

1.4 SBE (Simple Binary Encoding) — Evolusi FIX

SBE adalah format serialisasi biner yang dibuat oleh High Performance Working Group dalam FIX Trading Community. Misinya adalah menggantikan format FIX teks dengan representasi biner yang kompak untuk trading ultra-low-latency.

Prinsip Utama SBE:

• Zero-copy flyweight pattern — encoder dan decoder bertindak sebagai "template" di atas buffer. Nilai ditulis langsung tanpa salinan perantara (berbeda dengan Protobuf yang memerlukan beberapa).
• Wire format = memory format — data di jaringan terlihat sama seperti di memori, meminimalkan overhead transformasi.
• Fixed fields first, variable fields last — batasan desain yang memberikan performa satu tingkat lebih tinggi dibandingkan Protocol Buffers.

SBE + Aeron adalah kombinasi standar untuk sistem trading berkinerja tinggi. Aeron adalah sistem messaging open-source dari Real Logic (dibuat oleh Martin Thompson, mantan CTO LMAX Exchange, dan Todd Montgomery, mantan CTO 29West/Ultra Messaging). Ini secara efektif adalah transport layer khusus untuk sistem keuangan yang bekerja via UDP dan shared memory dengan latensi dalam hitungan mikrodetik tunggal. SBE menangani serialisasi, sementara Aeron mengelola pengiriman dengan penundaan mikrodetik. Lebih lanjut tentang Aeron di bagian 3.1.

1.5 Tabel Perbandingan Protokol Bursa

2. Komunikasi Microservice Internal

Setelah data masuk ke sistem Anda dari bursa, pemrosesan internal dimulai: parsing → strategi → keputusan → pengiriman order. Di setiap langkah, terdapat komunikasi antar-layanan.

2.1 gRPC Bidirectional Streaming (TCP)

gRPC adalah framework Google berbasis HTTP/2 yang menggunakan Protocol Buffers untuk serialisasi. Untuk algorithmic trading, bidirectional streaming sangat penting—ketika klien dan server secara bersamaan mengirimkan aliran pesan melalui satu koneksi.

Mengapa gRPC cocok untuk sistem trading:

• Protobuf kompak (3–10 kali lebih kecil dari JSON)
• Multiplexing HTTP/2 — beberapa stream dalam satu koneksi TCP
• Pengetikan ketat via skema .proto yang menangkap error saat kompilasi
• Pembuatan kode untuk Python, Rust, Go, C++, Java, dll.
• Bidirectional streaming memungkinkan pola "data pasar turun, order naik" via satu channel.

Menurut SmartDev, 70% lembaga keuangan yang menerapkan HFT berbasis AI menggunakan gRPC atau raw TCP untuk waktu respons mikrodetik.

Contoh arsitektur: Market Data Collector (Rust) → gRPC stream → Strategy Engine (Python/Rust) → gRPC call → Order Router (Rust) → WebSocket/FIX → Bursa.

2.2 gRPC via Unix Domain Socket (UDS)

Jika layanan berjalan di mesin yang sama (umum untuk co-location), TCP adalah overhead yang tidak perlu. Unix Domain Socket (UDS) melewati seluruh network stack: tidak ada TCP handshake, tidak ada routing, tidak ada checksumming.

Benchmark menunjukkan perbedaan signifikan:

• gRPC via UDS: ~102 μs/request (100K permintaan)
• gRPC via TCP: ~127 μs/request (100K permintaan)
• Keuntungan UDS: ~20% pada pesan kecil, hingga 50% pada pesan besar (100KB+).

Menurut F. Werner (MPI Heidelberg), membandingkan gRPC UDS dengan raw blocking I/O via UDS, gRPC menambahkan sekitar 10x overhead—median ~130 μs vs. ~13 μs untuk raw UDS. Ini adalah biaya abstraksi (framing HTTP/2, serialisasi protobuf).

Kapan menggunakan gRPC+UDS: Komunikasi antar-proses pada satu server ketika kemudahan developer (skema, codegen) lebih dihargai daripada latensi minimum absolut. UDS juga memberikan keunggulan keamanan via izin file Unix.

Kapan TIDAK menggunakan: Jika Anda membutuhkan latensi <10 μs, shared memory atau raw UDS tanpa gRPC lebih baik. Sebagai referensi: raw UDS median ~13 μs, gRPC UDS median ~130 μs. Shared memory (Aeron IPC) di bawah 1 μs, ring buffer LMAX Disruptor sekitar 50–100 ns. Dengan demikian gRPC+UDS ~10x lebih lambat dari raw UDS dan 100–1000x lebih lambat dari shared memory. Namun setiap langkah turun dalam latensi adalah langkah naik dalam kompleksitas kode.

Reproduksi sendiri: Semua angka latensi IPC di bagian ini dapat direproduksi dengan benchmark open-source suenot/trading-ipc-bench — implementasi Python dari TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory, dan round-trip Named Pipe, mengukur latensi p50/p95/p99/p99.9 dan throughput di hardware Anda sendiri.

Raw UDS tanpa gRPC — jika overhead gRPC berlebihan, hapus dan simpan hanya socketnya. Pilihan berdasarkan performa menurun:

• AF_UNIX sockets + serialisasi kustom (SBE, FlatBuffers, MessagePack) — ~13 μs median, kontrol maksimal, kompleksitas maksimal
• ZeroMQ IPC (ipc://) — ~50–100 μs, pola siap pakai (PUB/SUB, REQ/REP) tanpa boilerplate, menggunakan UDS di bawahnya
• nanomsg/NNG IPC — mirip ZeroMQ, latensi sedikit lebih baik pada pesan kecil (<64 KB)
• Cap'n Proto RPC over UDS — serialisasi zero-copy + abstraksi RPC, lebih cepat dari gRPC, memiliki skema

2.3 Shared Memory IPC

Untuk ultra-low-latency pada host yang sama, gunakan shared memory. Dua proses memetakan segmen RAM yang sama, dan data melewatinya tanpa syscall (kecuali untuk penyiapan awal).

Pola LMAX Disruptor (ring buffer dalam shared memory) menangani ~6 juta event per detik dalam satu thread. Pendekatan ini adalah inti dari LMAX Exchange dan banyak sistem HFT.

Implementasi: Aeron IPC (Java/C++), Chronicle Queue (Java), solusi berbasis mmap kustom (Rust/C++). IronSBE (implementasi Rust SBE) mendukung shared memory IPC dengan latensi ~20 ns di level channel SPSC.

3. Sistem Transport: Message Broker dan Library

3.1 Aeron — Standar Emas

Aeron adalah sistem transport pesan open-source berkinerja tinggi yang dikembangkan oleh Real Logic. Penciptanya adalah Martin Thompson (mantan CTO LMAX) dan Todd Montgomery (mantan CTO 29West). Dimulai pada 2014 untuk bursa besar di AS dan kini memiliki 70+ kontributor dan 5000+ subscriber GitHub.

Dalam praktik: Aeron bukan broker (seperti Kafka) maupun library socket (seperti ZeroMQ). Ini adalah transport layer yang dirancang untuk latensi rendah yang dapat diprediksi. Bekerja via UDP (jaringan) dan shared memory (IPC), menyediakan pengiriman yang andal, pengurutan, dan flow control—hal yang tidak dimiliki UDP mentah. Bayangkan Aeron sebagai "TCP dengan latensi UDP."

Karakteristik Aeron:

• Latensi: <100 μs di cloud, <18 μs pada bare metal.
• Throughput: >1 juta pesan/detik pada latensi mikrodetik.
• 20 juta+ pesan/detik pada puncak.
• Brokerless — tidak ada single point of failure.
• Mendukung unicast, multicast, dan IPC.
• Flow control dan deteksi kehilangan bawaan.

Aeron Cluster — replikasi state machine yang toleran terhadap kesalahan (konsensus Raft) untuk logika trading yang konsisten dengan penambahan latensi minimal.

Aeron Archive — persistensi pesan pada kecepatan stream penuh dengan kemampuan replay.

Aeron Sequencer — komponen terbaru dari ekosistem, dirancang untuk mengoordinasikan beberapa proyek di seluruh organisasi besar. Dibangun di atas Aeron Transport dan Aeron Cluster. Karakteristik utama:

• Distributed log — urutan panjang pesan yang direplikasi di beberapa mesin untuk toleransi kesalahan
• Multiple readers — beberapa aplikasi secara bersamaan membaca dari log yang sama untuk tujuan berbeda
• Decoupled teams — tim tetap independen sambil beroperasi dalam satu sistem terkoordinasi
• Target kasus penggunaan: pemrosesan data pasar, platform broker, mesin bursa

Perbandingan dengan Kafka: Keduanya menggunakan distributed log, tetapi Aeron untuk latensi mikrodetik, sedangkan Kafka untuk durabilitas dan throughput milidetik. Aeron ada untuk logika real-time; Kafka untuk pipeline data dan analitik.

3.2 Apache Kafka

Apache Kafka adalah standar faktual untuk event streaming dalam skala besar. Bukan untuk hot path trading (penundaan milidetik) tetapi tidak tergantikan untuk:

• Agregasi data pasar: mengumpulkan stream dari 100+ bursa ke dalam satu pipeline.
• Event sourcing: mencatat setiap tindakan sistem sebagai event topic.
• CDC (Change Data Capture): streaming perubahan DB trading ke analitik.
• Integrasi QuestDB: Kafka → QuestDB untuk analitik tick real-time.

Latensi adalah 2–15 ms end-to-end. Tidak dapat diterima untuk HFT, tetapi baik untuk strategi dengan horizon >1 detik.

3.3 Redis Pub/Sub dan Streams

Redis adalah in-memory store yang juga berfungsi sebagai broker ringan.

Redis Pub/Sub — fire-and-forget; latensi sub-milidetik. Ideal untuk notifikasi real-time: pembaruan harga, sinyal strategi, peringatan.

Redis Streams — menambahkan persistensi dan consumer group (mini-Kafka). Mendukung pembacaan riwayat dan ACK.

Redis lebih cepat dari Kafka untuk pesan kecil (sub-ms), tetapi kurang memiliki replikasi dan durabilitas berat Kafka.

3.4 NATS

NATS adalah sistem ultra-ringan dalam Go. Latensi sub-ms, pub/sub bawaan, request/reply. NATS JetStream menambahkan persistensi dan pengiriman exactly-once.

3.5 ZeroMQ dan nanomsg

Library brokerless yang menyediakan abstraksi socket untuk komunikasi peer-to-peer. ZeroMQ menangani 5 juta+ pesan/detik dan telah teruji sejak 2007. nanomsg (dan NNG) adalah "penerusnya" dengan latensi lebih baik pada pesan kecil (<64KB).

4. PUB/SUB Real-time untuk Klien: Centrifugo

Centrifugo adalah server PUB/SUB self-hosted dalam Go, dioptimalkan untuk broadcasting ke ribuan/jutaan klien via WebSocket, SSE, atau gRPC.

Mengapa Centrifugo untuk Algo Trading:

• Menangani 1 juta koneksi WebSocket dan 30 juta pesan/menit di satu server.
• Mendukung streaming 60Hz.
• Kompresi delta (algoritma Fossil) untuk meminimalkan traffic.
• Sempurna untuk "last mile" ke dashboard web atau aplikasi mobile.

5. Penyimpanan Data Akses Real-time

5.1 QuestDB — Time-Series untuk Trading

QuestDB adalah database time-series open-source yang ditulis dalam Java (zero-GC), C++, dan Rust.

• Query: Eksekusi vektorisasi sub-ms via SIMD.
• SAMPLE BY/ASOF JOIN: Ekstensi SQL native yang ramah trader.
• WAL: Append ultra-low-latency.
• Digunakan oleh B3 (bursa saham Brasil).

5.2 Redis sebagai Data Layer

Biasanya lapisan tengah:

• Hot cache untuk akses harga O(1).
• Sorted sets untuk order book.
• Lua scripts untuk operasi atomik.

5.3 Solusi Khusus: RayforceDB, AXL DB

Database vektor berbasis C yang minimalis (biner <1MB) dengan zero dependensi dan akselerasi SIMD. Fokus pada latensi deterministik untuk HFT.

6. Serialisasi: Protobuf vs SBE vs JSON

7. Arsitektur Referensi

7.1 Arbitrase Kripto (Frekuensi Menengah)

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

7.2 HFT Market Making (Co-location)

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

8. Saran Praktis

• <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 (Frekuensi Menengah): WebSocket, Kafka, Redis.
• >10 ms (Frekuensi Rendah / Swing): REST API sudah cukup. DCA, rebalancing, manajemen portofolio.

Jangan mengoptimalkan apa yang bukan bottleneck. Jika strategi Anda membutuhkan 50 ms untuk memutuskan, penghematan 100 μs dari Aeron tidak akan berarti. Arsitektur hybrid adalah normal: gunakan REST untuk setup, gRPC untuk inti, dan WS untuk pengiriman.

Repositori Benchmark

Angka latensi yang dikutip di seluruh artikel ini dapat direproduksi dengan suenot/trading-ipc-bench — suite benchmark Python open-source yang mencakup semua transport IPC utama yang dibahas di sini: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, dan Shared Memory.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # menjalankan semua 8 transport, menyimpan hasil ke results/
python report.py    # mencetak tabel ringkasan + grafik latensi ASCII

Jalankan di hardware Anda — hasilnya akan berbeda dari angka dalam artikel ini tergantung pada CPU, OS, versi kernel, dan tuning Anda. Itulah poinnya.

Kesimpulan

Tidak ada teknologi komunikasi yang "sempurna". Setiap level memiliki persyaratan unik: eksternal (kompatibilitas), internal (latensi), pipeline (keandalan), dan klien (fleksibilitas). Arsitektur adalah tentang memilih alat yang tepat untuk pekerjaan yang spesifik.