Разработка мультибиржевого торгового бота

Разработка мультибиржевого торгового бота

Мультибиржевой торговый бот — это не просто «бот с несколькими API-ключами». Это распределённая система исполнения ордеров, которая работает с несколькими exchange-коннекторами одновременно, синхронизирует состояние позиций и управляет капиталом между площадками в реальном времени. Здесь начинается настоящая инженерная работа.

Архитектура exchange-коннекторов

Первая задача — абстракция поверх разношёрстных API. Binance, OKX, Bybit, dYdX — у каждого своя модель данных, свои WebSocket-фиды, своя логика rate limiting. Стандартный подход: единый интерфейс ExchangeConnector с методами placeOrder, cancelOrder, getBalance, subscribeOrderBook. Под капотом каждый коннектор реализует протокол своей биржи.

ExchangeConnector (interface)
  ├── BinanceConnector   (REST + WS)
  ├── OKXConnector       (REST + WS)
  ├── BybitConnector     (REST + WS)
  └── dYdXConnector      (REST + WS + L1 settlements)

Проблемы, которые неизбежно вылезают:

• Разные форматы ордеров: Binance принимает symbol=BTCUSDT, OKX хочет instId=BTC-USDT. Нормализация — обязательный слой.
• Разные модели маржи: некоторые биржи unified margin, другие — по-инструментно. Это влияет на расчёт available balance.
• Разные rate limits: Binance считает weight запросов, Bybit — количество. Нужен адаптивный throttler с очередью запросов.

Синхронизация состояния позиций

Самое сложное — держать консистентный view позиций. Fill-события приходят через WebSocket с задержками, REST-поллинг добавляет latency, при сетевом сбое можно получить дублированные fills или пропустить частичное исполнение.

Решение: event sourcing поверх exchange-событий. Каждое событие (orderPlaced, orderFilled, orderCancelled) пишется в append-only лог, состояние портфеля восстанавливается воспроизведением. При reconnect делаем full reconciliation: сравниваем вычисленное состояние с REST-снапшотом биржи и применяем корректировки.

Стратегический слой и маршрутизация ордеров

Стратегии работают с абстрактным PortfolioManager, который не знает о конкретных биржах. Логика распределения капитала между площадками — отдельный компонент OrderRouter.

OrderRouter принимает решение, на какую биржу отправить ордер, основываясь на:

Cross-exchange арбитраж

Если задача — арбитраж между спотом на Binance и перпами на dYdX, нужна точная синхронизация времени исполнения. Используют два подхода: sequential (сначала одна нога, потом другая — несёт risk) и simultaneous (обе ноги одновременно через async tasks — всё равно несёт risk, но меньше). На практике чистого risk-free арбитража не бывает, всегда есть execution risk.

Управление рисками и капиталом

На уровне мультибиржевого бота critical компоненты:

Position Limits: максимальный размер позиции по каждому инструменту агрегировано по всем биржам. Если лонг на BTC 2 BTC на Binance и 1 BTC на OKX — суммарная экспозиция 3 BTC, и это нужно контролировать.

Capital Allocation: авто-ребалансировка свободного капитала между биржами. Если стратегия на Bybit исчерпала allocated capital, а на OKX остаток — перевод через internal accounting (физический перевод между биржами слишком медленный).

Failover: при недоступности одной биржи ордера маршрутизируются на альтернативную. Требует pre-configured fallback routing и мониторинга health статуса каждого коннектора.

Технологический стек

• Язык: Go или Rust для низкоlatency критических путей, Python для стратегий
• Очередь событий: Redis Streams или Kafka для event log
• Хранилище состояния: Redis для горячих данных, PostgreSQL для истории
• Мониторинг: Prometheus + Grafana, alert на аномалии latency и fill rates
• Деплой: Docker Compose для dev, Kubernetes с pod affinity для prod (ноды поближе к биржевым серверам)

Разработка такого бота — минимум 3-4 месяца для продакшен-готового решения с нормальной обработкой ошибок, reconciliation и monitoring. Быстрые прототипы на ccxt существуют, но в продакшене они ломаются на edge cases.