Дисклеймер: Информация в этой статье предоставлена исключительно в образовательных и ознакомительных целях и не является финансовым, инвестиционным или торговым советом. Торговля криптовалютами сопряжена с высоким риском убытков.
В алгоритмической торговле разница между прибылью и убытком может измеряться микросекундами. Архитектура передачи данных — один из ключевых факторов, определяющих эффективность торговой системы. В этой статье мы разберём технологии коммуникации на всех уровнях: от взаимодействия с биржей до внутренней межсервисной коммуникации, хранения и распространения данных.
Статья организована по уровням — от "внешнего" (протоколы связи с биржами) к "внутреннему" (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 — это синхронная модель. Отправив ордер, вы блокируете ресурсы пока ждёте ответ от биржи. Если биржа тормозит — тормозит вся ваша система.
Когда REST уместен: получение исторических данных (свечи, OHLCV), управление аккаунтом (баланс, позиции), операции, не требующие real-time (DCA-боты, ребалансировка раз в час).
1.2 WebSocket
WebSocket устанавливает одно персистентное TCP-соединение, через которое данные текут в обоих направлениях. Начинается как обычный HTTP-запрос с заголовком Upgrade, после чего переключается на двунаправленный бинарный протокол.
Преимущества для трейдинга:
Главное — нет 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, полностью переходя на асинхронную модель.
Гибридный подход (best practice): WebSocket для маркет-данных + WebSocket для ордеров (где поддерживается), REST для редких операций (исторические данные, настройка аккаунта).
1.3 FIX Protocol (Financial Information eXchange)
FIX — индустриальный стандарт электронной торговли, существующий с 1992 года (создан Fidelity Investments и Salomon Brothers). Это бинарный протокол поверх TCP, специально спроектированный для торговых операций.
Архитектура FIX:
Session layer — управление соединением, heartbeat, sequence numbering, gap recovery. Гарантирует доставку и порядок сообщений.
Почему 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, и Todd Montgomery, бывшим CTO 29West/Ultra Messaging). По сути это специализированный транспортный слой для финансовых систем, работающий поверх UDP и shared memory с латентностью в единицы микросекунд. В связке SBE отвечает за сериализацию сообщений в компактный бинарный формат, а Aeron — за их передачу с микросекундной задержкой. Подробнее об Aeron — в разделе 3.1.
1.5 Сравнительная таблица протоколов связи с биржей
Параметр
REST
WebSocket
FIX
FIX+SBE
Латентность
10–100+ мс
1–50 мс
10–500 мкс
1–100 мкс
Модель
Request-response
Bidirectional push
Bidirectional sessions
Bidirectional sessions
Ордера
Да (синхронно)
Да (асинхронно, не все биржи)
Да (нативно)
Да (нативно)
Прогрев соединения
Каждый запрос
Один раз
Один раз
Один раз
Формат
JSON/текст
JSON/binary
Tag-value текст
Binary
Сложность интеграции
Низкая
Средняя
Высокая
Очень высокая
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. Но каждый шаг вниз по латентности — это шаг вверх по сложности кода.
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. Отключившийся сервис может переподключиться и восстановить пропущенные сообщения.
Сравнение с Kafka: Оба используют distributed log, но Aeron оптимизирован под латентность (микросекунды), а Kafka — под пропускную способность и durability (миллисекунды). Aeron — для real-time торговой логики, Kafka — для data pipeline и аналитики.
3.2 Apache Kafka
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 коммуникации.
Автоматическое 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-систем
Система
Латентность (типичная)
Throughput
Persistence
Модель
Best for
Aeron
18–100 мкс
20M+ msg/s
Archive (опц.)
Brokerless
Hot path, matching
Kafka
2–15 мс
1M+ msg/s
Да (built-in)
Brokered
Event sourcing, pipeline
Redis Pub/Sub
<1 мс
1M+ msg/s
Нет
Brokered
Real-time notifications
Redis Streams
<1 мс
500K+ msg/s
Да
Brokered
Lightweight event log
NATS
<1 мс
10M+ msg/s
JetStream
Brokered
Microservices
ZeroMQ
<100 мкс
5M+ msg/s
Нет
Brokerless
IPC, fan-out
nanomsg/NNG
<100 мкс
3M+ msg/s
Нет
Brokerless
IPC, peer-to-peer
RabbitMQ
1–5 мс
50K+ msg/s
Да
Brokered
Complex routing
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 — нативная поддержка для исторических данных
Трёхуровневая архитектура хранения:
WAL (Write-Ahead Log) — ультра-low-latency append для входящих данных
Apache Parquet — колоночный формат хранения, идеальный для backtesting и аналитики:
Отличная компрессия (10:1 и выше для маркет-данных)
Predicate pushdown — чтение только нужных колонок и строк
Совместимость с Pandas, Polars, DuckDB, Spark
QuestDB нативно выгружает старые данные в Parquet
5.4 Нишевые решения: RayforceDB, AXL DB, ThePlatform
Помимо мейнстримных баз данных существуют специализированные проекты, заточенные именно под задачи трейдинга и аналитики с минимальным footprint.
RayforceDB (rayforcedb.com) — колоночная векторная БД на чистом 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 (axl-db.com) — "tiny vector database engine" от того же автора. Ещё более минималистичный: полностью помещается в CPU cache, не зависит даже от libc, статически линкуется. Фокус на детерминистической латентности под нагрузкой, что критично для HFT. Поддерживает beyond-RAM datasets и Lisp-подобный синтаксис запросов.
ThePlatform (theplatform.technology) — платформа для обработки и анализа 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-решений)
Всё критическое — in-house, open-source используется для инфраструктуры и тулинга
6. Сериализация: Protobuf vs SBE vs FlatBuffers vs JSON
Выбор формата сериализации напрямую влияет на латентность. Каждое сообщение в системе проходит encode → transmit → decode, и кодирование/декодирование может занимать больше времени, чем сама передача.
Формат
Encode/Decode
Размер
Zero-copy
Schema
Когда использовать
JSON
Медленный
Большой
Нет
Нет
REST API, дебаг, логи
Protobuf
Быстрый
Компактный
Нет
.proto
gRPC, межсервисная коммуникация
SBE
Ультра-быстрый
Минимальный
Да
XML schema
HFT, matching engines
FlatBuffers
Очень быстрый
Компактный
Да
.fbs
Gamedev, mobile, средний latency
Cap'n Proto
Очень быстрый
Компактный
Да
.capnp
IPC, RPC
MessagePack
Быстрый
Компактный
Нет
Нет
Замена JSON, WebSocket
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 на одной машине
>10 мс (low frequency): REST API вполне достаточен. DCA, ребалансировка, portfolio management.
Не оптимизируйте то, что не является bottleneck. Если ваша стратегия принимает решение за 50 мс, нет смысла тратить месяцы на переход с gRPC на Aeron ради экономии 100 мкс. Начните с профилирования end-to-end латентности: где реально теряется время?
Гибридные архитектуры — норма. По данным отрасли, более 60% enterprise AI-платформ используют гибридные протокольные архитектуры, комбинируя REST, gRPC и WebSocket для разных задач в одной системе.
Заключение
Идеальной универсальной технологии передачи данных для алготрейдинга не существует. Каждый уровень системы имеет свои требования: внешний — совместимость с биржами (WS, FIX), внутренний hot path — минимальная латентность (Aeron, shared memory, gRPC+UDS), data pipeline — надёжность и масштабируемость (Kafka, Redis Streams), клиентский — удобство и широта транспортов (Centrifugo, WebSocket).
Ключ к эффективной архитектуре — понимание требований каждого компонента и осознанный выбор технологии под конкретную задачу, а не попытка использовать одно решение для всего.
