एल्गो ट्रेडिंग सिस्टम में डेटा कम्युनिकेशन: एक तकनीकी अवलोकन

एल्गोरिदमिक ट्रेडिंग में, लाभ और हानि के बीच का अंतर माइक्रोसेकंड में मापा जा सकता है। डेटा ट्रांसमिशन आर्किटेक्चर उन प्रमुख कारकों में से एक है जो ट्रेडिंग सिस्टम की दक्षता निर्धारित करते हैं। इस लेख में, हम सभी स्तरों पर कम्युनिकेशन तकनीकों का विश्लेषण करेंगे: एक्सचेंज के साथ इंटरैक्शन से लेकर आंतरिक इंटर-सर्विस कम्युनिकेशन, स्टोरेज और डेटा डिस्ट्रीब्यूशन तक।

लेख को स्तरों के अनुसार व्यवस्थित किया गया है—"बाहरी" (एक्सचेंज प्रोटोकॉल) से "आंतरिक" (IPC, मैसेज ब्रोकर, स्टोरेज) तक—जो एक एल्गोरिदमिक ट्रेडिंग प्लेटफॉर्म की वास्तविक आर्किटेक्चर को दर्शाता है।

1. एक्सचेंज के साथ इंटरैक्शन: REST, WebSocket, FIX

1.1 REST API

REST एक्सचेंज API के साथ इंटरैक्ट करने का सबसे आसान और सबसे सामान्य तरीका है। प्रत्येक रिक्वेस्ट एक अलग HTTP कनेक्शन है: TCP हैंडशेक → TLS हैंडशेक → रिक्वेस्ट भेजें → रिस्पॉन्स प्राप्त करें → कनेक्शन बंद करें।

ट्रेडिंग के लिए REST की समस्याएँ:

प्रत्येक रिक्वेस्ट कनेक्शन सेटअप का ओवरहेड लेकर चलता है। HTTP keep-alive के साथ भी, "रिक्वेस्ट-रिस्पॉन्स" मॉडल का मतलब है कि आप रिक्वेस्ट भेजने से तेज़ी से डेटा प्राप्त नहीं कर सकते। इससे पोलिंग होती है—"क्या कोई नया डेटा है?" जैसे प्रश्नों का एक अनंत चक्र जो एक्सचेंज सर्वर पर 80% तक लोड बनाता है (क्रिप्टो एक्सचेंज डेवलपर्स के अनुसार)। एक्सचेंज रेट लिमिट लागू करते हैं (आमतौर पर प्रति मिनट 10–1200 रिक्वेस्ट), जिससे REST हाई-फ्रीक्वेंसी स्ट्रैटेजी के लिए अनुपयुक्त हो जाता है।

REST कब उपयुक्त है: ऐतिहासिक डेटा (कैंडल्स, OHLCV) प्राप्त करना, अकाउंट प्रबंधन (बैलेंस, पोज़िशन), गैर-रियल-टाइम ऑपरेशन (DCA बॉट्स, प्रति घंटा रीबैलेंसिंग)।

1.2 WebSocket

WebSocket एक स्थायी TCP कनेक्शन स्थापित करता है जिसके माध्यम से डेटा द्विदिशात्मक रूप से प्रवाहित होता है। यह Upgrade हेडर के साथ एक सामान्य HTTP रिक्वेस्ट के रूप में शुरू होता है, फिर द्विदिशात्मक फ्रेमिंग प्रोटोकॉल में बदल जाता है (पेलोड टेक्स्ट JSON या बाइनरी हो सकता है)।

ट्रेडिंग के लिए फायदे:

मुख्य फायदा यह है कि प्रति रिक्वेस्ट कोई ओवरहेड नहीं है। एक बार स्थापित होने पर, सर्वर द्वारा डेटा तुरंत पुश किया जाता है। WebSocket के माध्यम से मार्केट डेटा डिलीवरी की लेटेंसी आमतौर पर एक्सचेंज गेटवे से क्लाइंट तक 50 ms से कम होती है। आप एक ही कनेक्शन पर एक साथ 50+ सिंबल्स को सब्सक्राइब कर सकते हैं।

एक महत्वपूर्ण बिंदु: WebSocket के माध्यम से ऑर्डर। कई ट्रेडर्स को यह नहीं पता कि कुछ एक्सचेंज (Binance, HitBTC, Deribit, Bybit, आदि) सिर्फ डेटा प्राप्त करने के बजाय WebSocket के माध्यम से ऑर्डर भेजने की भी अनुमति देते हैं। यह मूल रूप से REST से तेज़ है क्योंकि:

• प्रत्येक ऑर्डर के लिए कोई TCP/TLS हैंडशेक नहीं (कनेक्शन पहले से ही "गर्म" है)
• कोई HTTP ओवरहेड नहीं (हेडर, कुकीज़, आदि)
• यह एसिंक्रोनस मॉडल है: आप एक ऑर्डर भेजते हैं और थ्रेड को ब्लॉक किए बिना उसी WebSocket के माध्यम से कन्फर्मेशन प्राप्त करते हैं।

Deribit के अनुसार, WebSocket और FIX में अक्सर समान एक्जीक्यूशन स्पीड होती है। REST कनेक्शन-स्तरीय प्रीप्रोसेसिंग के कारण थोड़ा धीमा है। WebSocket ऑर्डर्स ठीक FIX ऑर्डर्स की तरह ही मैचिंग इंजन क्यू में जाते हैं।

कॉन्टेक्स्ट मिक्सिंग समस्या। यदि आप REST के माध्यम से ऑर्डर भेजते हैं लेकिन WebSocket के माध्यम से एक्जीक्यूशन नोटिफिकेशन प्राप्त करते हैं, तो एक रेस कंडीशन होती है: WebSocket नोटिफिकेशन REST रिक्वेस्ट के पूरा होने से पहले आ सकता है। इससे स्टेट असंगति होती है। समाधान है ऑर्डर को उसी WebSocket के माध्यम से भेजना, पूरी तरह से एसिंक्रोनस मॉडल की ओर बढ़ना।

1.3 FIX प्रोटोकॉल (Financial Information eXchange)

FIX इलेक्ट्रॉनिक ट्रेडिंग के लिए इंडस्ट्रियल स्टैंडर्ड है, जो 1992 से मौजूद है (Fidelity Investments और Salomon Brothers द्वारा बनाया गया)। यह विशेष रूप से ट्रेडिंग के लिए डिज़ाइन किया गया TCP पर बाइनरी प्रोटोकॉल है।

FIX आर्किटेक्चर:

• सेशन लेयर — कनेक्शन, हार्टबीट, सीक्वेंस नंबरिंग, गैप रिकवरी को मैनेज करती है। मैसेज की डिलीवरी और क्रम की गारंटी देती है।
• एप्लिकेशन लेयर — बिज़नेस लॉजिक: ऑर्डर टाइप, एक्जीक्यूशन रिपोर्ट, मार्केट डेटा रिक्वेस्ट।

FIX मैसेज एक SOH कैरेक्टर से अलग किए गए "tag=value" जोड़ों से बने होते हैं। उदाहरण के लिए, AAPL के 100 शेयर $150 पर खरीदने का ऑर्डर इस तरह दिखता है:

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

FIX WebSocket से तेज़ क्यों है: FIX बिना HTTP लेयर्स के एक नेटिव TCP प्रोटोकॉल है। AWS, क्रिप्टो एक्सचेंज के लिए अपनी tick-to-trade ऑप्टिमाइज़ेशन गाइड में, प्रोटोकॉल-प्रेरित लेटेंसी को कम करने के लिए REST और WebSocket के बजाय स्पष्ट रूप से FIX की सिफारिश करता है। FIX माइक्रोसेकंड के स्तर पर काम करता है, जबकि WebSocket आमतौर पर मिलीसेकंड में होता है।

जहाँ FIX का दबदबा है: एक्सचेंज मैचिंग इंजन के लिए DMA (Direct Market Access), संस्थागत क्षेत्रों में एल्गोरिदमिक और HFT ट्रेडिंग, लिक्विडिटी एग्रीगेशन (प्राइम ब्रोकर्स FIX के माध्यम से दर्जनों बैंकों से कनेक्ट होते हैं)।

FIX की सीमाएँ: इंटीग्रेशन की जटिलता, पुराना मैसेज फॉर्मेट (टेक्स्चुअल tag-value बाइनरी फॉर्मेट की तुलना में कम कुशल हैं), प्रवेश की उच्च बाधा। क्रिप्टो इंडस्ट्री में, FIX सीमित संख्या में एक्सचेंज द्वारा समर्थित है।

1.4 SBE (Simple Binary Encoding) — इवोल्यूशनरी FIX

SBE FIX Trading Community के भीतर High Performance Working Group द्वारा बनाया गया एक बाइनरी सीरियलाइज़ेशन फॉर्मेट है। इसका मिशन टेक्स्ट FIX फॉर्मेट को अल्ट्रा-लो-लेटेंसी ट्रेडिंग के लिए एक कॉम्पैक्ट बाइनरी रिप्रेजेंटेशन से बदलना है।

SBE के मुख्य सिद्धांत:

• Zero-copy flyweight पैटर्न — एनकोडर और डिकोडर एक बफर पर "टेम्प्लेट" के रूप में कार्य करते हैं। वैल्यूज़ को बिना किसी इंटरमीडिएट कॉपी के सीधे लिखा जाता है (Protobuf के विपरीत, जिसे कई की आवश्यकता होती है)।
• वायर फॉर्मेट = मेमोरी फॉर्मेट — वायर पर डेटा बिल्कुल वैसा ही दिखता है जैसा मेमोरी में होता है, जिससे ट्रांसफॉर्मेशन ओवरहेड कम हो जाता है।
• पहले फिक्स्ड फील्ड्स, बाद में वैरिएबल फील्ड्स — एक डिज़ाइन बाधा जो Protocol Buffers की तुलना में एक ऑर्डर ऑफ मैग्नीट्यूड अधिक प्रदर्शन देती है।

SBE + Aeron हाई-परफॉरमेंस ट्रेडिंग सिस्टम के लिए मानक संयोजन है। Aeron Real Logic का एक ओपन-सोर्स मैसेजिंग सिस्टम है (जिसे Martin Thompson, पूर्व LMAX Exchange CTO, और Todd Montgomery, पूर्व 29West/Ultra Messaging CTO ने बनाया)। यह प्रभावी रूप से वित्तीय सिस्टम के लिए एक विशेष ट्रांसपोर्ट लेयर है जो UDP और शेयर्ड मेमोरी पर एकल-अंक माइक्रोसेकंड लेटेंसी के साथ काम करता है। SBE सीरियलाइज़ेशन को हैंडल करता है, जबकि Aeron माइक्रोसेकंड डिले के साथ डिलीवरी को मैनेज करता है। Aeron के बारे में अधिक जानकारी सेक्शन 3.1 में है।

1.5 एक्सचेंज प्रोटोकॉल की तुलना तालिका

2. आंतरिक माइक्रोसर्विस कम्युनिकेशन

एक बार जब डेटा एक्सचेंज से आपके सिस्टम में प्रवेश करता है, तो आंतरिक प्रोसेसिंग शुरू होती है: पार्सिंग → स्ट्रैटेजी → डिसीजन → ऑर्डर भेजना। प्रत्येक चरण में, इंटर-सर्विस कम्युनिकेशन होता है।

2.1 gRPC द्विदिशात्मक स्ट्रीमिंग (TCP)

gRPC एक Google फ्रेमवर्क है जो HTTP/2 पर आधारित है और सीरियलाइज़ेशन के लिए Protocol Buffers का उपयोग करता है। एल्गोरिदमिक ट्रेडिंग के लिए, द्विदिशात्मक स्ट्रीमिंग विशेष रूप से महत्वपूर्ण है—जब क्लाइंट और सर्वर एक ही कनेक्शन पर एक साथ मैसेज स्ट्रीम भेजते हैं।

gRPC ट्रेडिंग सिस्टम के लिए क्यों उपयुक्त है:

• Protobuf कॉम्पैक्ट है (JSON से 3–10 गुना छोटा)
• HTTP/2 मल्टीप्लेक्सिंग — एक TCP कनेक्शन पर कई स्ट्रीम
• .proto स्कीमा के माध्यम से सख्त टाइपिंग जो कंपाइल टाइम पर त्रुटियों को पकड़ती है
• Python, Rust, Go, C++, Java, आदि के लिए कोड जनरेशन
• द्विदिशात्मक स्ट्रीमिंग एक ही चैनल के माध्यम से "मार्केट डेटा नीचे, ऑर्डर ऊपर" पैटर्न को संभव बनाती है।

SmartDev के अनुसार, AI-driven HFT को डिप्लॉय करने वाले 70% वित्तीय संस्थान माइक्रोसेकंड रिस्पॉन्स टाइम के लिए gRPC या रॉ TCP का उपयोग करते हैं।

आर्किटेक्चर उदाहरण: Market Data Collector (Rust) → gRPC स्ट्रीम → Strategy Engine (Python/Rust) → gRPC कॉल → Order Router (Rust) → WebSocket/FIX → Exchange।

2.2 Unix Domain Socket (UDS) के माध्यम से gRPC

यदि सर्विसेज़ एक ही मशीन पर चलती हैं (को-लोकेशन के लिए विशिष्ट), तो TCP एक अनावश्यक ओवरहेड है। Unix Domain Socket (UDS) पूरे नेटवर्क स्टैक को बायपास करता है: कोई TCP हैंडशेक नहीं, कोई रूटिंग नहीं, कोई चेकसमिंग नहीं।

बेंचमार्क एक महत्वपूर्ण अंतर दिखाते हैं:

• UDS के माध्यम से gRPC: ~102 μs/रिक्वेस्ट (100K रिक्वेस्ट)
• TCP के माध्यम से gRPC: ~127 μs/रिक्वेस्ट (100K रिक्वेस्ट)
• UDS का फायदा: छोटे मैसेज पर ~20%, बड़े मैसेज (100KB+) पर 50% तक।

F. Werner (MPI Heidelberg) के अनुसार, UDS के माध्यम से रॉ ब्लॉकिंग I/O के साथ gRPC UDS की तुलना करते हुए, gRPC लगभग 10x ओवरहेड जोड़ता है—मीडियन ~130 μs बनाम रॉ UDS के लिए ~13 μs। यह एब्स्ट्रैक्शन की कीमत है (HTTP/2 फ्रेमिंग, protobuf सीरियलाइज़ेशन)।

gRPC+UDS का उपयोग कब करें: एक ही सर्वर पर इंटर-प्रोसेस कम्युनिकेशन जब डेवलपर की सुविधा (स्कीमा, कोडजेन) को पूर्ण न्यूनतम लेटेंसी से अधिक महत्व दिया जाता है। UDS Unix फाइल परमिशन के माध्यम से सुरक्षा लाभ भी प्रदान करता है।

कब उपयोग नहीं करें: यदि आपको <10 μs लेटेंसी चाहिए, तो शेयर्ड मेमोरी या gRPC के बिना रॉ UDS बेहतर है। संदर्भ के लिए: रॉ UDS मीडियन ~13 μs, gRPC UDS मीडियन ~130 μs। शेयर्ड मेमोरी (Aeron IPC) 1 μs से कम है, LMAX Disruptor रिंग बफर लगभग 50–100 ns है। इस प्रकार gRPC+UDS रॉ UDS से ~10x धीमा और शेयर्ड मेमोरी से 100–1000x धीमा है। लेकिन लेटेंसी में हर एक कदम कम कोड कॉम्प्लेक्सिटी में एक कदम ऊपर है।

इसे स्वयं दोहराएँ: इस सेक्शन के सभी IPC लेटेंसी नंबर ओपन-सोर्स कम्पैनियन बेंचमार्क suenot/trading-ipc-bench के साथ दोहराए जा सकते हैं — TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory, और Named Pipe राउंड-ट्रिप्स के Python इम्प्लीमेंटेशन, जो आपके अपने हार्डवेयर पर p50/p95/p99/p99.9 लेटेंसी और थ्रूपुट को मापते हैं।

gRPC के बिना रॉ UDS — यदि gRPC ओवरहेड अत्यधिक है, तो इसे हटा दें और केवल सॉकेट रखें। घटते प्रदर्शन क्रम में विकल्प:

• AF_UNIX सॉकेट + कस्टम सीरियलाइज़ेशन (SBE, FlatBuffers, MessagePack) — ~13 μs मीडियन, अधिकतम नियंत्रण, अधिकतम जटिलता
• ZeroMQ IPC (ipc://) — ~50–100 μs, बिना बॉयलरप्लेट के तैयार पैटर्न (PUB/SUB, REQ/REP), अंदर से UDS का उपयोग करता है
• nanomsg/NNG IPC — ZeroMQ के समान, छोटे मैसेज (<64 KB) पर थोड़ी बेहतर लेटेंसी
• Cap'n Proto RPC UDS पर — zero-copy सीरियलाइज़ेशन + RPC एब्स्ट्रैक्शन, gRPC से तेज़, स्कीमा है

2.3 शेयर्ड मेमोरी IPC

एक ही होस्ट पर अल्ट्रा-लो-लेटेंसी के लिए, शेयर्ड मेमोरी का उपयोग करें। दो प्रोसेस एक ही RAM सेगमेंट को मैप करते हैं, और डेटा बिना सिस्टम कॉल्स के गुज़रता है (इनिशियल सेटअप को छोड़कर)।

LMAX Disruptor पैटर्न (शेयर्ड मेमोरी में रिंग बफर) एक ही थ्रेड पर प्रति सेकंड ~60 लाख इवेंट्स को हैंडल करता है। यह अप्रोच LMAX Exchange और कई HFT सिस्टम्स का हृदय है।

इम्प्लीमेंटेशन: Aeron IPC (Java/C++), Chronicle Queue (Java), कस्टम mmap-आधारित समाधान (Rust/C++)। IronSBE (Rust SBE इम्प्लीमेंटेशन) SPSC चैनल स्तर पर ~20 ns लेटेंसी के साथ शेयर्ड मेमोरी IPC को सपोर्ट करता है।

3. ट्रांसपोर्ट सिस्टम: मैसेज ब्रोकर और लाइब्रेरीज़

3.1 Aeron — गोल्ड स्टैंडर्ड

Aeron Real Logic द्वारा विकसित एक ओपन-सोर्स हाई-परफॉरमेंस मैसेज ट्रांसपोर्ट सिस्टम है। इसके निर्माता Martin Thompson (पूर्व LMAX CTO) और Todd Montgomery (पूर्व 29West CTO) हैं। यह 2014 में एक बड़े US एक्सचेंज के लिए शुरू हुआ और अब इसके 70+ कंट्रीब्यूटर्स और 5000+ GitHub सब्सक्राइबर्स हैं।

व्यवहार में: Aeron न तो एक ब्रोकर है (Kafka की तरह) और न ही एक सॉकेट लाइब्रेरी (ZeroMQ की तरह)। यह प्रेडिक्टेबल लो लेटेंसी के लिए डिज़ाइन किया गया एक ट्रांसपोर्ट लेयर है। यह UDP (नेटवर्क) और शेयर्ड मेमोरी (IPC) पर काम करता है, जो विश्वसनीय डिलीवरी, ऑर्डरिंग और फ्लो कंट्रोल प्रदान करता है—ऐसी चीज़ें जो रॉ UDP में नहीं होतीं। Aeron को "UDP लेटेंसी वाला TCP" समझें।

Aeron की विशेषताएँ:

• लेटेंसी: क्लाउड में <100 μs, बेयर मेटल पर <18 μs।
• थ्रूपुट: माइक्रोसेकंड लेटेंसी पर >1M मैसेज/s।
• 20M+ मैसेज/s पीक।
• ब्रोकरलेस — कोई सिंगल पॉइंट ऑफ फेलियर नहीं।
• यूनिकास्ट, मल्टीकास्ट और IPC को सपोर्ट करता है।
• बिल्ट-इन फ्लो कंट्रोल और लॉस डिटेक्शन।

Aeron Cluster — न्यूनतम अतिरिक्त लेटेंसी के साथ लगातार ट्रेडिंग लॉजिक के लिए फॉल्ट-टॉलरेंट स्टेट मशीन रेप्लिकेशन (Raft consensus)।

Aeron Archive — रीप्ले क्षमता के साथ फुल स्ट्रीम स्पीड पर मैसेज पर्सिस्टेंस।

Aeron Sequencer — इकोसिस्टम का सबसे नया घटक, जो बड़े संगठनों में कई प्रोजेक्ट्स को समन्वित करने के लिए डिज़ाइन किया गया है। यह Aeron Transport और Aeron Cluster के ऊपर बनाया गया है। मुख्य विशेषताएँ:

• डिस्ट्रिब्यूटेड लॉग — फॉल्ट टॉलरेंस के लिए कई मशीनों पर रेप्लिकेटेड मैसेज का एक लंबा क्रम
• मल्टीपल रीडर्स — कई एप्लिकेशन विभिन्न उद्देश्यों के लिए एक साथ उसी लॉग को पढ़ते हैं
• डिकपल्ड टीमें — टीमें एक समन्वित सिस्टम के भीतर काम करते हुए भी स्वतंत्र बनी रहती हैं
• लक्षित उपयोग के मामले: मार्केट डेटा प्रोसेसिंग, ब्रोकर प्लेटफॉर्म, एक्सचेंज इंजन

Kafka के साथ तुलना: दोनों एक डिस्ट्रिब्यूटेड लॉग का उपयोग करते हैं, लेकिन Aeron माइक्रोसेकंड लेटेंसी के लिए है, जबकि Kafka मिलीसेकंड ड्यूरेबिलिटी और थ्रूपुट के लिए है। Aeron रियल-टाइम लॉजिक के लिए मौजूद है; Kafka डेटा पाइपलाइनों और एनालिटिक्स के लिए।

3.2 Apache Kafka

Apache Kafka स्केल पर इवेंट स्ट्रीमिंग के लिए वास्तविक मानक है। यह ट्रेड हॉट पाथ (मिलीसेकंड डिले) के लिए नहीं है, लेकिन इसके लिए अपरिहार्य है:

• मार्केट डेटा एग्रीगेशन: 100+ एक्सचेंज से स्ट्रीम को एक पाइपलाइन में एकत्र करना।
• इवेंट सोर्सिंग: हर सिस्टम एक्शन को एक इवेंट टॉपिक के रूप में रिकॉर्ड करना।
• CDC (Change Data Capture): ट्रेडिंग DB में बदलावों को एनालिटिक्स में स्ट्रीम करना।
• QuestDB इंटीग्रेशन: रियल-टाइम टिक एनालिटिक्स के लिए Kafka → QuestDB।

लेटेंसी एंड-टू-एंड 2–15 ms है। HFT के लिए अस्वीकार्य, लेकिन >1s होराइज़न वाली स्ट्रैटेजी के लिए ठीक है।

3.3 Redis Pub/Sub और Streams

Redis एक इन-मेमोरी स्टोर है जो एक हल्के ब्रोकर के रूप में भी काम करता है।

Redis Pub/Sub — fire-and-forget; सब-मिलीसेकंड लेटेंसी। रियल-टाइम नोटिफिकेशन के लिए आदर्श: प्राइस अपडेट, स्ट्रैटेजी सिग्नल, अलर्ट।

Redis Streams — पर्सिस्टेंस और कंज्यूमर ग्रुप्स (मिनी-Kafka) जोड़ता है। हिस्ट्री पढ़ने और ACKs को सपोर्ट करता है।

छोटे मैसेज के लिए Redis Kafka से तेज़ है (सब-ms), लेकिन इसमें Kafka की भारी रेप्लिकेशन और ड्यूरेबिलिटी की कमी है।

3.4 NATS

NATS Go में लिखा गया एक अल्ट्रा-लाइटवेट सिस्टम है। सब-ms लेटेंसी, बिल्ट-इन pub/sub, request/reply। NATS JetStream पर्सिस्टेंस और exactly-once डिलीवरी जोड़ता है।

3.5 ZeroMQ और nanomsg

पीयर-टू-पीयर कम्युनिकेशन के लिए सॉकेट एब्स्ट्रैक्शन प्रदान करने वाली ब्रोकरलेस लाइब्रेरीज़। ZeroMQ 5M+ मैसेज/s को हैंडल करता है और 2007 से प्रोडक्शन में परखा गया है। nanomsg (और NNG) इसका "उत्तराधिकारी" है जिसमें छोटे मैसेज (<64KB) पर बेहतर लेटेंसी है।

4. क्लाइंट्स के लिए रियल-टाइम PUB/SUB: Centrifugo

Centrifugo Go में लिखा गया एक सेल्फ-होस्टेड PUB/SUB सर्वर है, जो WebSocket, SSE, या gRPC के माध्यम से हज़ारों/लाखों क्लाइंट्स को ब्रॉडकास्ट करने के लिए ऑप्टिमाइज़ किया गया है।

Algo Trading के लिए Centrifugo क्यों:

• एक सर्वर पर 1M WebSocket कनेक्शन और 30M मैसेज/मिनट हैंडल करता है।
• 60Hz स्ट्रीमिंग को सपोर्ट करता है।
• ट्रैफिक को कम करने के लिए डेल्टा कंप्रेशन (Fossil एल्गोरिदम)।
• वेब डैशबोर्ड या मोबाइल ऐप्स तक "लास्ट माइल" के लिए एकदम सही।

5. रियल-टाइम एक्सेस डेटा स्टोर

5.1 QuestDB — ट्रेडिंग के लिए टाइम-सीरीज़

QuestDB Java (zero-GC), C++, और Rust में लिखा गया एक ओपन-सोर्स टाइम-सीरीज़ डेटाबेस है।

• क्वेरीज़: SIMD के माध्यम से सब-ms वेक्टराइज़्ड एक्जीक्यूशन।
• SAMPLE BY/ASOF JOIN: नेटिव ट्रेडर-फ्रेंडली SQL एक्सटेंशन।
• WAL: अल्ट्रा-लो-लेटेंसी अपेंड।
• B3 (ब्राज़ील का स्टॉक एक्सचेंज) द्वारा उपयोग किया जाता है।

5.2 डेटा लेयर के रूप में Redis

आमतौर पर एक मिडिल लेयर:

• O(1) प्राइस एक्सेस के लिए हॉट कैश।
• ऑर्डरबुक्स के लिए सॉर्टेड सेट्स।
• एटॉमिक ऑपरेशंस के लिए Lua स्क्रिप्ट्स।

5.3 विशेष समाधान: RayforceDB, AXL DB

बिना किसी डिपेंडेंसी और SIMD एक्सेलरेशन के साथ C-आधारित मिनिमलिस्ट वेक्टर डेटाबेस (बाइनरी <1MB)। HFT के लिए डिटर्मिनिस्टिक लेटेंसी पर फोकस।

6. सीरियलाइज़ेशन: Protobuf बनाम SBE बनाम JSON

7. रेफरेंस आर्किटेक्चर

7.1 क्रिप्टो आर्बिट्रेज (मीडियम फ्रीक्वेंसी)

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

7.2 HFT मार्केट मेकिंग (को-लोकेशन)

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

8. व्यावहारिक सलाह

• <10 μs (HFT): FPGA, शेयर्ड मेमोरी, SBE, Aeron IPC।
• 10–100 μs: Aeron (UDP), gRPC+UDS, ZeroMQ।
• 100 μs – 1 ms: gRPC (TCP), WebSocket, Protobuf।
• 1–10 ms (मीडियम फ्रीक्वेंसी): WebSocket, Kafka, Redis।
• >10 ms (लो फ्रीक्वेंसी / स्विंग): REST API पर्याप्त है। DCA, रीबैलेंसिंग, पोर्टफोलियो मैनेजमेंट।

जो बॉटलनेक नहीं है उसे ऑप्टिमाइज़ न करें। यदि आपकी स्ट्रैटेजी को निर्णय लेने में 50 ms लगते हैं, तो Aeron की 100 μs की बचत मायने नहीं रखेगी। हाइब्रिड आर्किटेक्चर सामान्य हैं: सेटअप के लिए REST, कोर के लिए gRPC, और डिलीवरी के लिए WS का उपयोग करें।

बेंचमार्क रिपॉज़िटरी

इस लेख में उद्धृत लेटेंसी नंबर्स को suenot/trading-ipc-bench के साथ दोहराया जा सकता है — यहाँ चर्चा किए गए सभी प्रमुख IPC ट्रांसपोर्ट को कवर करने वाला एक ओपन-सोर्स Python बेंचमार्क सूट: TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, और 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

इसे अपने हार्डवेयर पर चलाएँ — परिणाम इस लेख के नंबर्स से आपके CPU, OS, कर्नेल वर्ज़न और ट्यूनिंग के आधार पर अलग होंगे। यही तो मुद्दा है।

निष्कर्ष

कोई "परफेक्ट" कम्युनिकेशन तकनीक नहीं है। हर स्तर की अनूठी आवश्यकताएँ होती हैं: बाहरी (कम्पैटिबिलिटी), आंतरिक (लेटेंसी), पाइपलाइन (रिलायबिलिटी), और क्लाइंट (फ्लेक्सिबिलिटी)। आर्किटेक्चर विशिष्ट कार्य के लिए सही टूल चुनने के बारे में है।