Ми — команда блокчейн-інженерів з 5+ років досвіду в розробці HFT-ботів та DeFi-рішень. Розробляємо системи hot-swap стратегій для торгових ботів, які дозволяють замінити стратегію на льоту, без зупинки, без втрати відкритих позицій, без downtime. Для маркет-мейкерів та HFT-операторів це критично: кожна хвилина простою — втрачений spread income. Для всіх інших — це зручність оперування та швидкість реакції на зміну ринкових умов. Hot-swap кращий за рестарт у 10 разів за часом простою, що при частоті замін раз на тиждень дає економію до 86 хвилин downtime на рік.
Архітектурний фундамент: Strategy Interface
Hot-swap можливий лише якщо стратегії реалізовані через єдиний інтерфейс. Бот працює не з конкретною стратегією, а з абстрактним Strategy об'єктом. Заміна стратегії — це зміна об'єкта, що реалізує інтерфейс.
class Strategy(ABC): @abstractmethod def on_tick(self, market_data: MarketData) -> Optional[Signal]: """Викликається при кожному оновленні ринкових даних""" pass @abstractmethod def on_fill(self, fill: Fill) -> None: """Викликається при виконанні ордера""" pass @abstractmethod def get_state(self) -> StrategyState: """Повертає поточний стан для передачі наступнику""" pass @abstractmethod def restore_state(self, state: StrategyState) -> None: """Відновлює стан від попередника""" pass Методи get_state та restore_state — ключові для hot-swap. При заміні стратегії поточний стан передається новій стратегії: відкриті позиції, накопичені метрики, market context.
Як працює протокол заміни стратегії?
Наївний hot-swap — просто замінити об'єкт — небезпечний. Якщо заміна відбувається в момент обробки сигналу, можна отримати inconsistent state. Потрібен атомарний протокол:
Фаза 1: Prepare
- Повідомити поточну стратегію про майбутню заміну
- Стратегія завершує поточний цикл (не починає нові операції)
- Стратегія серіалізує свій стан
Фаза 2: Transition
- Атомарна заміна об'єкта стратегії (з блокуванням)
- Передача стану новій стратегії
- Нова стратегія відновлює контекст
Фаза 3: Verify
- Перевірка, що нова стратегія коректно ініціалізувалася
- Запуск першого циклу на новій стратегії
- Якщо помилка — відкат до попередньої стратегії
Весь перехід займає мілісекунди. Для HFT це помітно, для більшості стратегій — ні.
Динамічне завантаження плагінів
Для дійсно гнучкого hot-swap — стратегії як плагіни, що завантажуються в runtime. У Python використовуємо importlib.import_module + reload:
import importlib import importlib.util def load_strategy_from_file(filepath: str, class_name: str) -> Type[Strategy]: spec = importlib.util.spec_from_file_location("dynamic_strategy", filepath) module = importlib.util.module_from_spec(spec) spec.loader.exec_module(module) return getattr(module, class_name) У Go — plugin package для завантаження .so файлів, або gRPC-based strategy runner (стратегія як окремий процес). Sandboxing обов'язковий для multi-tenant систем: запускаємо плагіни в ізольованих контейнерах.
Управління версіями стратегій
При hot-swap важливо знати, яка версія стратегії працює зараз. Приклад метаданих:
{ "strategy_id": "trend_following_v2", "version": "2.3.1", "deployed_at": "2025-01-15T14:30:00Z", "deployed_by": "operator", "previous_version": "2.2.0", "change_description": "Покращено entry filter по ATR" } Canary deployment: нова стратегія запускається з 10% капіталу, стара з 90%. Якщо нова показує хороші результати — поступово перемикаємо. Якщо гірша — відкочуємо без втрат. A/B testing: дві версії працюють паралельно на різних інструментах або в різні часові вікна, результати порівнюються статистично.
Що передавати при перемиканні?
Не весь стан потрібно передавати при hot-swap:
| Тип стану | Передавати? | Причина |
|---|---|---|
| Відкриті позиції | Так | Нова стратегія повинна керувати ними |
| Накопичений P&L | Так | Для лімітів та моніторингу |
| Internal ML model state | Залежить | Якщо стратегія змінюється кардинально — немає сенсу |
| Order history | Ні | Береться із загального логу |
| Market data buffer | Так | Для стратегій, що потребують історичного контексту |
Якщо стратегія A — trend following, а на неї перемикається стратегія B — mean reversion, передача внутрішніх сигналів A безглузда. Але відкриті позиції та риск-ліміти — завжди.
Тестування hot-swap
Це критично: механізм, який не тестувався — не працює, коли потрібен.
- Unit тести: перемикання між mock стратегіями, перевірка передачі стану
- Integration тести: перемикання під навантаженням (10 тіків/сек), перевірка відсутності пропущених сигналів
- Chaos testing: перемикання в момент виконання ордера, при втраті з'єднання з біржею
- Production drill: періодично робити плановий hot-swap у prod для впевненості, що механізм працює
Hot-swap стратегій — engineering feat середнього рівня складності. Основна робота не в механізмі заміни, а в правильному проектуванні Strategy interface з урахуванням всіх edge cases передачі стану.
Що входить в роботу
При замовленні розробки системи hot-swap ми надаємо:
- Архітектурну документацію (Strategy Interface, протокол заміни)
- Вихідний код з повним coverage unit-тестів
- Інтеграцію з вашим ботом (під ключ)
- Документацію з експлуатації та troubleshooting
- Гарантію безперебійної роботи механізму протягом 12 місяців
Ми виконали 15+ проєктів з розробки торгових ботів за 5 років на ринку. Зв'яжіться з нами, щоб обговорити ваш кейс. Замовте розробку бота з hot-swap — оцінимо проєкт протягом 2 робочих днів.