Коммуникация данных в алготрейдинговых системах: обзор технологий

В алгоритмической торговле разница между прибылью и убытком может измеряться микросекундами. Архитектура передачи данных — один из ключевых факторов, определяющих эффективность торговой системы. В этой статье мы разберём технологии коммуникации на всех уровнях: от взаимодействия с биржей до внутренней межсервисной коммуникации, хранения и распространения данных.

Статья организована по уровням — от "внешнего" (протоколы связи с биржами) к "внутреннему" (IPC, message brokers, хранилища), что отражает реальную архитектуру алготрейдинговой платформы.

---

1. Взаимодействие с биржей: REST, WebSocket, FIX

1.1 REST API

REST — самый простой и распространённый способ взаимодействия с биржевым API. Каждый запрос — это отдельное HTTP-соединение: TCP handshake → TLS handshake → отправка запроса → получение ответа → закрытие соединения.

Проблемы REST для трейдинга:

Каждый запрос несёт на себе overhead установки соединения. Даже с HTTP keep-alive, модель "запрос-ответ" означает, что вы не можете получать данные быстрее, чем отправляете запросы. Это приводит к polling — бесконечному циклу опросов "а есть ли новые данные?", который создаёт до 80% нагрузки на биржевые серверы (по оценкам разработчиков криптобирж). Биржи вводят rate limits (обычно 10–1200 запросов в минуту), что делает REST непригодным для высокочастотных стратегий.

Когда REST уместен: получение исторических данных (свечи, OHLCV), управление аккаунтом (баланс, позиции), операции, не требующие real-time (DCA-боты, ребалансировка раз в час).

1.2 WebSocket

WebSocket устанавливает одно персистентное TCP-соединение, через которое данные текут в обоих направлениях. Начинается как обычный HTTP-запрос с заголовком Upgrade, после чего переключается на двунаправленный фреймовый протокол (payload может быть как текстовым JSON, так и бинарным).

Преимущества для трейдинга:

Главное — нет overhead на каждый запрос. Соединение установлено один раз, и дальше данные push'атся сервером мгновенно. Задержка доставки маркет-данных по WebSocket обычно составляет менее 50 мс от шлюза биржи до клиента. Через одно соединение можно подписаться на 50+ символов одновременно.

Критически важный момент: ордера через WebSocket. Многие трейдеры не знают, что некоторые биржи (Binance, HitBTC, Deribit, Bybit и другие) позволяют отправлять ордера через WebSocket — не только получать данные. Это принципиально быстрее, чем REST, потому что:

• Нет TCP/TLS handshake на каждый ордер (соединение уже "прогрето")
• Нет HTTP overhead (заголовки, cookie, и т.д.)
• Асинхронная модель: отправил ордер — получил подтверждение через тот же WebSocket, не блокируя поток

По данным Deribit, WebSocket и FIX в большинстве случаев имеют одинаковую скорость исполнения. REST немного медленнее из-за pre-processing на уровне соединения. При этом WebSocket-ордера попадают в очередь биржевого matching engine так же, как FIX-ордера.

Проблема смешивания контекстов. Если вы отправляете ордера через REST, а нотификации об их исполнении получаете через WebSocket, возникает race condition: уведомление по WebSocket может прийти раньше, чем завершится REST-запрос. Это ведёт к несогласованности состояния. Решение — отправлять ордера через тот же WebSocket, полностью переходя на асинхронную модель.

1.3 FIX Protocol (Financial Information eXchange)

FIX — индустриальный стандарт электронной торговли, существующий с 1992 года (создан Fidelity Investments и Salomon Brothers). Это бинарный протокол поверх TCP, специально спроектированный для торговых операций.

Архитектура FIX:

• Session layer — управление соединением, heartbeat, sequence numbering, gap recovery. Гарантирует доставку и порядок сообщений.
• Application layer — бизнес-логика: типы ордеров, execution reports, market data requests.

Сообщения FIX представляют собой пары "тег=значение", разделённые SOH-символом. Например, ордер на покупку 100 акций AAPL по $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 — это нативный TCP-протокол без HTTP-прослоек. AWS в своём руководстве по оптимизации tick-to-trade для криптобирж прямо рекомендует FIX перед REST и WebSocket для минимизации protocol-induced latency. FIX оперирует на уровне микросекунд, тогда как WebSocket — обычно миллисекунды.

Где FIX доминирует: DMA (Direct Market Access) к matching engine биржи, алгоритмический и HFT-трейдинг в институциональном пространстве, агрегация ликвидности (prime broker подключается к десяткам банков через FIX).

Ограничения FIX: сложность интеграции, устаревший формат сообщений (текстовые тег-значения неэффективны по сравнению с бинарными форматами), высокий порог входа. В криптоиндустрии FIX поддерживается ограниченным числом бирж.

1.4 SBE (Simple Binary Encoding) — эволюция FIX

SBE — это бинарный формат сериализации, созданный High Performance Working Group внутри FIX Trading Community. Задача — заменить текстовый формат FIX на компактное бинарное представление для ультра-low-latency торговли.

Ключевые принципы SBE:

• Zero-copy flyweight pattern — энкодеры и декодеры работают как "трафарет" поверх буфера. Значения записываются прямо в буфер без промежуточных копий (в отличие от Protobuf, который требует несколько копий).
• Wire format = memory format — данные на проводе выглядят так же, как в памяти, что минимизирует overhead трансформации.
• Фиксированные поля в начале, переменные — в конце — это ограничение дизайна, но оно даёт на порядок большую производительность по сравнению с Protocol Buffers.

SBE + Aeron — стандартная комбинация для высокопроизводительных торговых систем. Aeron — это open-source система передачи сообщений от Real Logic (создана Martin Thompson, бывшим CTO биржи LMAX Exchange, и Todd Montgomery, бывшим CTO 29West/Ultra Messaging). По сути это специализированный транспортный слой для финансовых систем, работающий поверх UDP и shared memory с латентностью в единицы микросекунд. В связке SBE отвечает за сериализацию сообщений в компактный бинарный формат, а Aeron — за их передачу с микросекундной задержкой. Подробнее об Aeron — в разделе 3.1.

1.5 Сравнительная таблица протоколов связи с биржей

---

2. Внутренняя межсервисная коммуникация

Когда данные попали в вашу систему с биржи, начинается внутренняя обработка: парсинг маркет-данных → стратегия → принятие решения → отправка ордера. На каждом этапе — межсервисная коммуникация.

2.1 gRPC Bidirectional Streaming (TCP)

gRPC — фреймворк от Google на базе HTTP/2, использующий Protocol Buffers для сериализации. Для алготрейдинга особенно важен bidirectional streaming — когда клиент и сервер одновременно отправляют потоки сообщений через одно соединение.

Почему gRPC подходит для торговых систем:

• Protobuf — компактный бинарный формат (в 3–10 раз меньше JSON)
• HTTP/2 мультиплексирование — несколько потоков через одно TCP-соединение
• Строгая типизация через .proto схемы — ошибки ловятся на этапе компиляции
• Кодогенерация для Python, Rust, Go, C++, Java и других языков
• Bidirectional streaming позволяет реализовать паттерн "маркет-данные вниз, ордера вверх" через один канал

По данным SmartDev, 70% финансовых институтов, развёртывающих HFT с использованием AI, применяют gRPC или raw TCP для достижения микросекундного времени отклика.

Пример архитектуры: Market Data Collector (Rust) → gRPC stream → Strategy Engine (Python/Rust) → gRPC call → Order Router (Rust) → WebSocket/FIX → Биржа.

2.2 gRPC через Unix Domain Socket (UDS)

Если сервисы работают на одной машине (что типично для co-location), TCP — это лишний overhead. Unix Domain Socket (UDS) убирает весь сетевой стек: нет TCP handshake, нет routing, нет checksumming.

Бенчмарки показывают существенную разницу:

• gRPC через UDS: ~102 мкс/запрос (100K запросов)
• gRPC через TCP: ~127 мкс/запрос (100K запросов)
• Выигрыш UDS: ~20% на мелких сообщениях, до 50% на крупных (100KB+)

По замерам F. Werner (MPI Heidelberg), при сравнении gRPC UDS с raw blocking I/O через UDS, gRPC добавляет примерно 10x overhead — медиана ~130 мкс против ~13 мкс для raw UDS. Это плата за удобство абстракции (HTTP/2 framing, protobuf serialization).

Когда использовать gRPC+UDS: межпроцессная коммуникация на одном сервере, когда важнее удобство разработки (schema, codegen) чем абсолютная минимизация латентности. UDS также даёт преимущество в безопасности — Unix file permissions контролируют доступ.

Когда НЕ использовать: если нужна латентность <10 мкс, лучше shared memory или raw UDS без gRPC. Конкретные цифры: raw blocking I/O через UDS — медиана ~13 мкс, gRPC через UDS — медиана ~130 мкс (замеры F. Werner, MPI Heidelberg на AMD EPYC). Shared memory (Aeron IPC) — менее 1 мкс, LMAX Disruptor ring buffer — порядка 50–100 нс на событие. То есть gRPC+UDS проигрывает raw UDS примерно в 10 раз, а shared memory — в 100–1000 раз быстрее gRPC. Но каждый шаг вниз по латентности — это шаг вверх по сложности кода.

Воспроизведите сами: цифры из этого раздела можно измерить на своём железе с помощью открытого бенчмарка suenot/trading-ipc-bench — Python-реализации TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, Shared Memory и Named Pipe с измерением p50/p95/p99/p99.9 задержки и throughput.

Raw UDS без gRPC — если overhead gRPC избыточен, убираем его, оставляя только сокет. Варианты по убыванию производительности:

• AF_UNIX сокеты + кастомная сериализация (SBE, FlatBuffers, MessagePack) — ~13 мкс медиана, максимальный контроль, максимальная сложность
• ZeroMQ IPC (ipc://) — ~50–100 мкс, готовые паттерны (PUB/SUB, REQ/REP) без boilerplate, использует UDS под капотом
• nanomsg/NNG IPC — аналогично ZeroMQ, чуть лучше латентность на малых сообщениях (<64 KB)
• Cap'n Proto RPC over UDS — zero-copy сериализация + RPC-абстракция, быстрее gRPC, есть schema

2.3 Shared Memory IPC

Для ультра-low-latency на одном хосте — shared memory. Два процесса маппят один и тот же участок RAM, и данные передаются без каких-либо syscall'ов (кроме начальной настройки).

Паттерн LMAX Disruptor (ring buffer в shared memory) демонстрирует обработку ~6 миллионов событий в секунду на одном потоке. Этот подход лежит в основе архитектуры LMAX Exchange и многих HFT-систем.

Реализации: Aeron IPC (Java/C++), Chronicle Queue (Java), custom mmap-based solutions (Rust/C++). IronSBE (Rust-реализация SBE) поддерживает shared memory IPC с латентностью ~20 наносекунд на уровне SPSC-канала.

---

3. Транспортные системы: Message Brokers и Messaging Libraries

3.1 Aeron — стандарт для торговых систем

Aeron — это open-source высокопроизводительная система передачи сообщений (message transport), разработанная компанией Real Logic. Создатели — Martin Thompson (бывший CTO LMAX Exchange, автор LMAX Disruptor) и Todd Montgomery (бывший CTO 29West, разработчик Ultra Messaging — широко используемой low-latency messaging системы в финансах). Разработка началась в 2014 году по заказу крупной американской биржи; сейчас проект насчитывает 70+ контрибьюторов и 5000+ подписчиков на GitHub.

Что такое Aeron на практике: это не message broker (как Kafka или RabbitMQ) и не библиотека сокетов (как ZeroMQ). Aeron — это именно транспортный слой, заточенный под предсказуемую низкую латентность. Он работает поверх UDP (для сетевой коммуникации) и shared memory (для IPC на одном хосте), при этом обеспечивая reliable delivery, ordering и flow control — то, чего обычный UDP не гарантирует. Можно думать об Aeron как о "TCP с латентностью UDP".

Aeron поддерживает Java, C/C++ и .NET, что делает его доступным для большинства торговых стеков.

Характеристики Aeron:

• Латентность: менее 100 мкс в облаке, менее 18 мкс на физическом железе
• Пропускная способность: более 1 миллиона сообщений/сек при микросекундной латентности
• 20+ миллионов сообщений/сек на пике
• Brokerless — нет центрального брокера, нет single point of failure
• Поддержка unicast, multicast и IPC
• Встроенные механизмы flow control, congestion control, message loss detection

Aeron Cluster — расширение для fault-tolerant state machine replication. По сути это Raft-консенсус для торговых систем, обеспечивающий consistent replication с минимальной добавленной латентностью.

Aeron Archive — персистентность сообщений на диск с полной скоростью потока, с возможностью replay. Отключившийся сервис может переподключиться и восстановить пропущенные сообщения.

Aeron Sequencer — новейший компонент экосистемы, предназначенный для координации множества проектов в рамках крупных организаций. Построен на базе Aeron Transport и Aeron Cluster. Ключевые характеристики:

• Distributed log — длинная последовательность сообщений, реплицированная на несколько машин для отказоустойчивости
• Multiple readers — несколько приложений одновременно читают один и тот же лог для разных задач
• Decoupled teams — команды остаются независимыми, но работают в рамках единой координируемой системы
• Ориентирован на: обработку рыночных данных, брокерские платформы, биржевые движки

Сравнение с Kafka: Оба используют distributed log, но Aeron оптимизирован под латентность (микросекунды), а Kafka — под пропускную способность и durability (миллисекунды). Aeron — для real-time торговой логики, Kafka — для data pipeline и аналитики.

3.2 Apache Kafka

Apache Kafka — стандарт де-факто для event streaming в масштабе. Не подходит для hot path торговой логики (задержки в миллисекундах), но незаменим для:

• Агрегация маркет-данных: собирать потоки с 100+ бирж в единый pipeline
• Event sourcing: каждое действие системы записывается как событие в topic
• CDC (Change Data Capture): стриминг изменений из trading DB в аналитику
• Интеграция с QuestDB: Kafka → QuestDB для real-time аналитики тиковых данных

Kafka обеспечивает durability (данные реплицируются по брокерам), ordering (внутри партиции) и replay (можно перечитать историю). Для low-latency конфигурации: acks=0 (fire-and-forget), отключение persistence, партиционирование по символам.

Типичная латентность Kafka: 2–15 мс end-to-end при правильной настройке. Для HFT неприемлемо, но для стратегий с горизонтом >1 сек — вполне.

3.3 Redis Pub/Sub и Redis Streams

Redis — in-memory хранилище, работающее также как lightweight message broker.

Redis Pub/Sub — fire-and-forget: если subscriber был offline, сообщения потеряны. Латентность sub-миллисекундная на мелких сообщениях. Идеален для real-time нотификаций: обновления цен, сигналы стратегий, alerts.

Redis Streams — добавляет persistence и consumer groups (аналог Kafka в миниатюре). Можно читать историю, подтверждать обработку (ACK), масштабировать consumers.

В контексте трейдинга Redis используется как:

• Real-time cache для текущих цен (SET/GET с TTL)
• Pub/Sub слой для распространения сигналов между стратегиями
• Rate limiter для контроля частоты запросов к биржам
• Leaderboard для мониторинга производительности стратегий

Redis быстрее Kafka на мелких сообщениях (sub-мс до p99), но не имеет встроенной репликации и durability сопоставимой с Kafka.

3.4 NATS

NATS — ультралёгкий messaging system, написанный на Go. Минимальная архитектурная сложность, sub-миллисекундная латентность, встроенная поддержка pub/sub, request/reply и queue groups.

NATS JetStream — расширение с persistence, exactly-once delivery и stream processing. Хорошая альтернатива Kafka для проектов среднего масштаба.

Centrifugo (real-time pub/sub сервер) поддерживает NATS как backend для горизонтального масштабирования — удобно для распространения маркет-данных на web-клиенты.

3.5 ZeroMQ и nanomsg — brokerless messaging

ZeroMQ и его "наследник" nanomsg — это библиотеки (не серверы), предоставляющие socket-абстракции для peer-to-peer коммуникации.

ZeroMQ:

• Паттерны: PUB/SUB, REQ/REP, PUSH/PULL, DEALER/ROUTER
• Пропускная способность: 5+ миллионов сообщений/сек на отправку
• Транспорты: TCP, IPC (Unix Domain Socket), inproc (внутри процесса)
• Автоматическое batch'инг сообщений для максимизации throughput
• Battletested с 2007 года, огромное сообщество

nanomsg (и NNG — next gen):

• Более чистое API, pluggable транспорты и протоколы
• Лучшая латентность на маленьких сообщениях (до 64 KB)
• Дополнительные паттерны: SURVEY (опрос всех peer'ов)
• ZeroMQ лидирует на больших сообщениях (>64 KB) по throughput

Для трейдинга: ZeroMQ/nanomsg хороши как "клей" между компонентами системы, особенно когда нужна гибкость топологии (fan-out маркет-данных, pipeline обработки). Но нет гарантии доставки — сообщения могут быть потеряны. Для ордеров нужен дополнительный acknowledgment-слой.

3.6 Сравнительная таблица messaging-систем

---

4. Real-time PUB/SUB для клиентов: Centrifugo

Centrifugo — self-hosted PUB/SUB-сервер на Go, поддерживающий WebSocket, HTTP-streaming, SSE, gRPC и WebTransport. Оптимизирован для broadcast-сценариев: одно сообщение → тысячи/миллионы клиентов.

Почему Centrifugo для алготрейдинга:

• Тест с 1 миллионом WebSocket-соединений и 30 миллионами доставленных сообщений в минуту на оборудовании одного сервера
• Стриминг данных с частотой 60 Гц (продемонстрировано на телеметрии Assetto Corsa → Grafana)
• Горизонтальное масштабирование через Redis Cluster, Valkey, KeyDB, DragonflyDB или NATS
• Channel history с автоматическим recovery при reconnect
• Delta compression (алгоритм Fossil) для минимизации трафика
• JSON и binary Protobuf форматы

Типичный сценарий: Backend собирает маркет-данные → обрабатывает → публикует через Centrifugo API → Centrifugo раздаёт всем подключённым WebSocket-клиентам (web-интерфейс, мобильные приложения, мониторинг).

Для внутренней коммуникации между компонентами трейдинговой системы Centrifugo — overkill. Здесь лучше gRPC, Aeron или ZeroMQ. Centrifugo — это именно "последняя миля" до пользователя или дашборда.

---

5. Хранилища данных с real-time access

5.1 QuestDB — time-series для трейдинга

QuestDB — open-source time-series база данных, оптимизированная для финансовых и промышленных данных. Написана на Java (zero-GC), C++ и Rust.

Ключевые возможности для трейдинга:

• Ingestion: терабайты в день, миллионы строк в секунду на одном сервере
• Queries: sub-миллисекундные, векторизованное выполнение с SIMD-инструкциями
• SAMPLE BY — нативная агрегация по временным интервалам (свечи, OHLCV)
• ASOF JOIN — join по ближайшему timestamp'у (критично для market data alignment)
• LATEST ON — получение последнего значения для каждого символа
• 2D arrays — нативные массивы для снимков orderbook'а
• Materialized views — continuous OHLC rollups с REFRESH IMMEDIATE
• Parquet support — нативная поддержка для исторических данных

Трёхуровневая архитектура хранения:

1. WAL (Write-Ahead Log) — ультра-low-latency append для входящих данных
2. Columnar storage — time-partitioned, дедуплицированный, мгновенно queryable
3. Object storage — автоматическая выгрузка старых данных в Parquet

B3 (бразильская фондовая биржа, крупнейшая в Латинской Америке) использует QuestDB для real-time операций с securities.

5.2 Redis как real-time data layer

В контексте трейдинга Redis часто выступает как промежуточный слой:

• Hot cache текущих цен: O(1) доступ к последней цене любого инструмента
• Sorted sets для orderbook: ZADD book:BTC:bids price amount, O(log N) на вставку
• TTL для автоматического протухания стейлых данных
• Lua scripts для атомарных операций (проверка + обновление в одном вызове)

Типичный стек: Биржа → WebSocket collector → Redis (hot cache + pub/sub) → QuestDB (persistence + analytics).

5.3 Parquet для исторических данных

Apache Parquet — колоночный формат хранения, идеальный для backtesting и аналитики:

• Отличная компрессия (10:1 и выше для маркет-данных)
• Predicate pushdown — чтение только нужных колонок и строк
• Совместимость с Pandas, Polars, DuckDB, Spark
• QuestDB нативно выгружает старые данные в Parquet

5.4 Нишевые решения: RayforceDB, AXL DB, ThePlatform

Помимо мейнстримных баз данных существуют специализированные проекты, заточенные именно под задачи трейдинга и аналитики с минимальным footprint.

RayforceDB — колоночная векторная БД на чистом C от Антона Кунденко (singaraiona). Бинарник менее 1 МБ, ноль зависимостей, SIMD-векторизация (AVX2/NEON), кросс-платформенность включая WASM. Lisp-подобный язык запросов Rayfall. По заявлению авторов, "battle-tested в финансовой аналитике и HFT-окружениях". Есть биндинги для Python (rayforce-py с DataFrame API), Rust (rayforce-rs), VS Code-расширение и WASM-версия для браузера. Development partnership с Lynx Capital.

AXL DB — "tiny vector database engine" от того же автора. Ещё более минималистичный: полностью помещается в CPU cache, не зависит даже от libc, статически линкуется. Фокус на детерминистической латентности под нагрузкой, что критично для HFT. Поддерживает beyond-RAM datasets и Lisp-подобный синтаксис запросов.

ThePlatform — платформа для обработки и анализа real-time и исторических данных, также от singaraiona. Позиционируется как альтернатива KDB+/Q с более современным подходом. Включает встроенные "reagent"-типы для IPC, TCP, UDP, WebSocket, TLS — то есть коммуникационные примитивы интегрированы прямо в язык. Поддержка KDB-совместимости через плагин. Это интересный подход: вместо отдельной БД + отдельного транспорта + отдельного языка запросов — всё в одной среде.

Все три проекта объединяет философия "минимализм + производительность": нулевые зависимости, крошечный binary, SIMD-first. Для алготрейдинга это означает: предсказуемая латентность (нет GC, нет аллокаций на hot path), простота деплоя, возможность встраивания прямо в торговый процесс.

5.5 Что используют крупные квантовые фонды

Хотя HFT-фирмы крайне закрыты в отношении своих технологий, некоторые детали известны из публичных вакансий, open-source проектов и выступлений.

Jane Street — использует OCaml как основной язык для всего: от торговых систем до автоматизации и исследований. Выпустила в open-source около миллиона строк кода, включая: Core (альтернативная стандартная библиотека OCaml), Async (кооперативная конкурентность с блокирующими операциями, выраженными в системе типов), Incremental (самокорректирующиеся вычисления — пересчитывает только то, что изменилось, идеально для market data), magic-trace (трассировка производительности с наносекундным разрешением), Hardcaml (проектирование hardware на OCaml — вероятно, для FPGA-стратегий). В 2025 году анонсировали OxCaml — свой форк компилятора с расширениями для performance engineering: fearless concurrency, контроль над layout данных в памяти, нативный доступ к SIMD, контроль аллокаций для снижения GC-давления.

Citadel Securities — обрабатывает ~35% объёма торгов акциями в США (около $500 млрд/день). Из вакансий известно: KDB+/Q для time-series аналитики, Python для стратегий и data science, C++ для low-latency систем, FPGA для критических участков (наносекундная торговая логика, прошитая в железо). CTO Citadel Securities Josh Woods публично говорил о важности постоянного обновления технологического стека, чтобы не потерять гибкость.

Two Sigma — активно использует Apache Kafka и Apache Spark, выпустила Flint (time-series library для Spark), Cook (планировщик задач поверх Mesos). Стек: Python, Java, C++.

Общие паттерны крупных фондов:

• KDB+/Q остаётся стандартом для time-series аналитики на торговых десках (хотя QuestDB, DuckDB и ClickHouse набирают популярность)
• FPGA для hardware-accelerated торговой логики (наносекундная латентность)
• Custom proprietary messaging (часто на базе Aeron или собственных UDP-решений)
• Kernel bypass networking (DPDK, Solarflare/Xilinx ef_vi)
• Всё критическое — in-house, open-source используется для инфраструктуры и тулинга

---

6. Сериализация: Protobuf vs SBE vs FlatBuffers vs JSON

Выбор формата сериализации напрямую влияет на латентность. Каждое сообщение в системе проходит encode → transmit → decode, и кодирование/декодирование может занимать больше времени, чем сама передача.

SBE даёт на порядок большую производительность за счёт ограничений: фиксированные поля в начале сообщения, переменные — только в конце. Для торговых сообщений (ордер, execution report, market data update) эти ограничения несущественны.

LinkedIn публично задокументировал, что переход с JSON на Protobuf дал заметное улучшение латентности на p99. SBE обещает ещё большее преимущество за счёт flyweight-паттерна.

---

7. Эталонные архитектуры

7.1 Криптоарбитраж (средняя частота)

Биржа A ──WS──┐
Биржа B ──WS──┤──▶ Market Data Collector (Rust)
Биржа C ──WS──┘         │
                    Redis Pub/Sub + Cache
                         │
                    Strategy Engine (Python)
                         │
                    gRPC (UDS) ──▶ Order Router (Rust) ──WS──▶ Биржи
                         │
                    Kafka ──▶ QuestDB (аналитика)
                         │
                    Centrifugo ──WS──▶ Web Dashboard

Обоснование выборов:

• WS к биржам: хорошая задержка + простота подключения к 100+ биржам
• Redis: hot cache цен + fan-out сигналов
• gRPC UDS: typed коммуникация между strategy и order router на одной машине
• Kafka: reliable pipeline для записи в QuestDB
• Centrifugo: real-time дашборд для мониторинга

7.2 HFT Market Making (co-location)

Exchange Feed ──FIX/UDP Multicast──▶ NIC (kernel bypass)
                                        │
                                   Aeron IPC (shared memory)
                                        │
                                   Strategy (C++, single thread)
                                        │
                                   SBE encode ──▶ Aeron ──▶ FIX ──▶ Exchange
                                        │
                                   Aeron Archive ──▶ QuestDB (post-trade)

Обоснование:

• Kernel bypass NIC (Solarflare/Xilinx) — обход OS сетевого стека
• Aeron IPC — shared memory, наносекундная латентность
• Single-threaded strategy — нет synchronization overhead
• SBE — zero-copy сериализация
• FIX — прямой доступ к matching engine
• Всё на одном сервере в co-location

7.3 Data Platform (StockAPIs-подобная)

100+ бирж ──WS──▶ Collector Fleet (Rust)
                        │
                   Kafka (партиции по биржа:символ)
                        │
            ┌───────────┼───────────┐
            ▼           ▼           ▼
     Redis (hot)   QuestDB (ts)   Parquet (cold)
            │           │
            └─────┬─────┘
                  ▼
         gRPC API + Centrifugo WS
                  │
            ┌─────┼─────┐
            ▼     ▼     ▼
         Clients / Bots / AI Agents

Обоснование:

• Kafka: единый backbone, горизонтальное масштабирование коллекторов
• Трёхуровневое хранение: Redis (hot, <1мс), QuestDB (warm, <10мс), Parquet (cold, batch)
• gRPC API: typed, efficient, bidirectional streaming для клиентов
• Centrifugo: WebSocket для web/mobile клиентов с delta compression

---

8. Практические рекомендации

Правило выбора технологии по латентности стратегии:

• <10 мкс (HFT): FPGA, kernel bypass, shared memory, SBE, Aeron IPC, raw UDP. Всё на одной машине в co-location.
• 10–100 мкс (ultra-low): Aeron (UDP), gRPC+UDS, ZeroMQ inproc/IPC, SBE или Protobuf. Один или несколько серверов в одной стойке.
• 100 мкс – 1 мс (low latency): gRPC (TCP), WebSocket, ZeroMQ TCP, Protobuf. Несколько серверов, возможно в разных AZ.
• 1–10 мс (medium frequency): WebSocket к биржам, Kafka внутри, Redis cache. Стандартная cloud инфраструктура.
• >10 мс (low frequency / swing): REST API вполне достаточен. DCA, ребалансировка, portfolio management.

Не оптимизируйте то, что не является bottleneck. Если ваша стратегия принимает решение за 50 мс, нет смысла тратить месяцы на переход с gRPC на Aeron ради экономии 100 мкс. Начните с профилирования end-to-end латентности: где реально теряется время?

Гибридные архитектуры — норма. По данным отрасли, более 60% enterprise AI-платформ используют гибридные протокольные архитектуры, комбинируя REST, gRPC и WebSocket для разных задач в одной системе.

---

Репозиторий с бенчмарками

Все цифры задержек, упомянутые в этой статье, можно воспроизвести с помощью suenot/trading-ipc-bench — открытого Python-бенчмарка для восьми IPC-транспортов: 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   # запустить все 8 транспортов, результаты → results/
python report.py    # сводная таблица + ASCII-график

Запустите на своём железе — результаты будут отличаться от приведённых в статье в зависимости от CPU, ОС и версии ядра. Это и есть смысл.

---

Заключение

Идеальной универсальной технологии передачи данных для алготрейдинга не существует. Каждый уровень системы имеет свои требования: внешний — совместимость с биржами (WS, FIX), внутренний hot path — минимальная латентность (Aeron, shared memory, gRPC+UDS), data pipeline — надёжность и масштабируемость (Kafka, Redis Streams), клиентский — удобство и широта транспортов (Centrifugo, WebSocket).

Ключ к эффективной архитектуре — понимание требований каждого компонента и осознанный выбор технологии под конкретную задачу, а не попытка использовать одно решение для всего.