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

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

Мультибіржовий торговий бот — це не просто "бот з кількома API-ключами". Це розподілена система виконання ордерів, яка працює з кількома коннекторами біржі одночасно, синхронізує стан позицій і управляє капіталом між платформами в реальному часі. Тут починається справжня інженерна робота.

Архітектура коннекторів біржі

Першим завданням є абстракція поверх різнорідних 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, інші — за інструментом. Це впливає на розрахунок доступного балансу.
• Різні rate limits: Binance лічить вагу запитів, Bybit — кількість. Потрібен адаптивний дросель з чергою запитів.

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

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

Рішення: event sourcing поверх подій біржі. Кожна подія (orderPlaced, orderFilled, orderCancelled) записується у append-only журнал, стан портфоліо відновлюється відтворенням. При повторному підключенні повна синхронізація: порівнюємо обчислений стан із REST-знімком біржі та застосовуємо корекції.

Стратегічний шар та маршрутизація ордерів

Стратегії працюють з абстрактним PortfolioManager, який не знає конкретних бірж. Логіка розповсюдження капіталу між платформами — окремий компонент OrderRouter.

OrderRouter приймає рішення про те, на яку біржу надіслати ордер на основі:

Крос-біржовий арбітраж

Якщо ціль — арбітраж між спотом на Binance та перпами на dYdX, потрібна точна синхронізація часу виконання. Використовуються два підходи: послідовний (одна нога потім інша — несе ризик) та одночасний (обидві ноги одночасно через async tasks — все одно несе ризик але менше). На практиці чистого risk-free арбітражу не буває, execution risk завжди залишається.

Управління ризиками та капіталом

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

Position Limits: максимальний розмір позиції за кожним інструментом агреговано по всім біржам. Якщо long 2 BTC на Binance і 1 BTC на OKX — загальна експозиція 3 BTC, потрібно контролювати.

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

Failover: при недоступності однієї біржи ордери маршрутизуються на альтернативну. Потребує заздалегідь налаштованої резервної маршрутизації та моніторингу здоров'я кожного коннектора.

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

• Мова: Go або Rust для низькоlatency критичних шляхів, Python для стратегій
• Event Queue: Redis Streams або Kafka для event log
• State Storage: Redis для гарячих даних, PostgreSQL для історії
• Monitoring: Prometheus + Grafana, alert на аномалії latency та fill rates
• Deployment: Docker Compose для dev, Kubernetes з pod affinity для prod (вузли ближче до серверів бірж)

Розробка такого бота займає мінімум 3-4 місяці для production-ready рішення з нормальною обробкою помилок, reconciliation та monitoring. Швидкі прототипи на ccxt існують, але в production вони ломаються на edge cases.