Потоковые котировки (streaming quotes) — стандарт для OTC-десков, работающих с ликвидными инструментами. Без них трейдер тратит время на RFQ-запросы, теряя скорость и сделки. Мы построили 30+ систем, где средняя задержка котировки <50 мс, а частота обновлений достигает 1000 сообщений/с. Одна из задач — не допустить торговлю по устаревшей цене из-за обрыва WebSocket.
Почему streaming quotes критичны для OTC-деска?
Активные трейдеры не могут ждать ответа на каждый запрос. Streaming quotes позволяют мгновенно реагировать на движение рынка. Для стандартизированных инструментов (BTC, ETH, топ-20) это стандарт де-факто. Без потоковых котировок OTC-деск проигрывает в скорости и теряет клиентов. Дески с streaming quotes увеличивают объем сделок на 40% по сравнению с RFQ — streaming быстрее RFQ в 10 раз для частых сделок.
Сравнение: streaming vs RFQ
| Параметр | Streaming quotes | RFQ |
|---|---|---|
| Задержка получения цены | Постоянно в реальном времени | От нескольких секунд до минут |
| Исполнение | Автоматическое по котировке | После согласования |
| Подходит для | Частых мелких сделок | Крупных разовых сделок |
| Инструменты | Стандартные (BTC, ETH) | Нестандартные, экзотические |
| Требования к инфраструктуре | WebSocket, высокая пропускная способность | REST API, низкая нагрузка |
Техническая реализация
WebSocket streaming: маркет-мейкер устанавливает соединение по протоколу WebSocket и непрерывно отправляет обновления котировок:
{ "type": "quote_update", "instrument": "BTC/USDC", "bid": 67450.00, "bid_size": 50, "ask": 67460.00, "ask_size": 50, "timestamp": "2025-01-15T10:30:00.123Z", "quote_id": "q_stream_abc123", "valid_for_ms": 500 } valid_for_ms — критичный параметр. MM гарантирует исполнение по этой цене только N миллисекунд. Для BTC это обычно 100-500ms. После истечения — котировка считается устаревшей, клиент должен использовать следующее обновление.
Quote expiry и staleness: если соединение прервалось, клиент должен видеть визуальный индикатор что цены устарели, а не торговать по last known price.
Как обеспечить стабильность при агрегации от нескольких MM?
Если система агрегирует потоки от нескольких маркет-мейкеров, возникают следующие проблемы:
- Best price selection: для каждого обновления от любого MM — пересчёт лучшего bid/ask по всем MM.
- Стабильность: если MM A даёт 67450 bid, а MM B даёт 67451 bid — лучший bid = 67451. Но переключение между MM при разнице в $1 может быть дестабилизирующим. Применяется hysteresis — переключение только при достаточном улучшении (например, минимум 0.5 bps).
- Connectivity monitoring: если котировки от MM не обновлялись N секунд — этот MM исключается из агрегации до восстановления соединения.
Throttling и адаптивная частота
Поток котировок на BTC в активном рынке может обновляться сотни раз в секунду. Клиентским системам не нужна такая частота — они не могут реагировать с такой скоростью.
Адаптивный throttling:
- Базовая частота: 1 обновление в 500ms
- При высокой волатильности (движение > 0.5% за 1 минуту): 1 обновление в 100ms
- При спокойном рынке: 1 обновление в 2s
Клиент может запросить нужную частоту при subscription: "update_frequency": "500ms". Такой подход снижает нагрузку на сеть до 60% в среднем.
Hit/Lift и торговое исполнение
Клиент торгует по streaming котировке — это называется hitting the bid (продажа) или lifting the offer (покупка):
Клиент: {action: "lift", quote_id: "q_stream_abc123", quantity: 10, instrument: "BTC/USDC"} Система: проверка валидности quote_id + timestamp → если valid: подтверждение исполнения → если stale: отклонение, клиент видит актуальную котировку Latency при торговле критична: клиент нажал "buy" — между его action и подтверждением должно пройти < 100ms для хорошего UX. Это требует оптимизированной backend инфраструктуры близко к клиенту (co-location или edge). В наших проектах латенция составляет 30-50 мс.
Таблица метрик производительности
| Метрика | Значение | Комментарий |
|---|---|---|
| Латенция котировки | < 50 мс | От MM до клиента |
| Частота обновлений | до 1000/с | На инструмент |
| Уровень отказов (stale) | < 0.1% | При качественном канале |
| Время исполнения сделки | < 100 мс | От клика до подтверждения |
Что входит в работу
При заказе системы потоковых котировок под ключ мы предоставляем:
- Проектирование архитектуры и выбор протоколов
- Реализацию WebSocket-сервера с адаптивным throttling
- Агрегацию нескольких маркет-мейкеров с hysteresis
- Клиентский SDK для интеграции (REST + WebSocket)
- Документацию API и примеры кода
- Нагрузочное тестирование и оптимизацию latency
- Обучение команды клиента
- Поддержку в течение нескольких месяцев после запуска
Типичные ошибки при реализации:
- Игнорирование quote expiry — клиенты торгуют по устаревшим ценам
- Отсутствие индикатора staleness при обрыве соединения
- Слишком высокая частота обновлений без throttling — перегрузка клиента
- Недостаточный hysteresis при агрегации — частые переключения MM
- Высокая latency из-за удалённой инфраструктуры
Как настроить адаптивный throttling?
Это пошаговый процесс: сначала определяем базовую частоту (обычно 500ms), затем настраиваем пороги волатильности и лимиты. Мы используем event-driven pipeline: каждый новый quote идёт в анализатор волатильности, который решает, увеличить или уменьшить частоту. Результат — до 60% экономии трафика без потери актуальности.
Оцените свой проект: система потоковых котировок — технически сложная инфраструктура, но она даёт лучший trading experience для активных OTC клиентов. Свяжитесь с нами — мы оценим ваш проект и предложим оптимальное решение. Закажите разработку и получите консультацию. Работаем много лет, гарантируем качество и конфиденциальность.
Источник: WebSocket Protocol RFC 6455