Разработка системы ордеров (limit, market, stop)

Разработка системы ордеров (limit, market, stop)

Запуск криптобиржи: баг в matching engine может за секунды обнулить ликвидность. Ошибка в обработке рыночного ордера способна вызвать slippage на 20% и отток пользователей. Мы разработали десятки торговых систем за 5+ лет и знаем, как избежать этих рисков. Наш matching engine на Go достигает latency <1 мс на уровне order book, что в 10 раз быстрее типичных реализаций на Node.js. Мы используем btree для хранения price levels и бедлок-фри структуры для конкурентного доступа. В результате система выдерживает до 100 000 ордеров в секунду на одном инстансе. Средняя экономия на инфраструктуре по сравнению с решениями на Node.js достигает 40%, а срок окупаемости составляет 6–9 месяцев. Ниже — детали реализации и ключевые архитектурные решения.

Типы ордеров и их семантика

Limit order

Пользователь указывает цену и объём. Ордер исполняется только если рынок достигнет указанной цены или лучше.

• Buy limit: исполняется по цене ≤ указанной
• Sell limit: исполняется по цене ≥ указанной
• Может быть частично исполнен (partial fill)
• Неисполненная часть остаётся в order book

Дополнительные модификаторы: GTC (Good Till Cancelled), GTD (Good Till Date), IOC (Immediate Or Cancel), FOK (Fill Or Kill), Post-Only.

Market order

Исполняется немедленно по лучшей доступной цене. Гарантирует исполнение, но не гарантирует цену. На неликвидных рынках возможен значительный slippage. Безопасная реализация включает лимит slippage — если исполнение требует прохождения более чем на X%, ордер отклоняется с ошибкой PRICE_IMPACT_TOO_HIGH.

Stop order

Триггерный ордер. Активируется когда цена достигает stop price. После активации превращается в market или limit.

• Stop-Market: при достижении stop price создаётся market ордер
• Stop-Limit: при достижении stop price создаётся limit ордер с указанным limit price
• Trailing Stop: stop price следует за рынком на заданное расстояние

Stop ордера не находятся в order book — они хранятся отдельно в stop orders storage и мониторятся по изменению цены.

Архитектура matching engine

Структура данных order book

Классическая реализация — два sorted map (bid side и ask side) с ценой как ключом. В каждом price level — очередь ордеров (FIFO для price-time priority).

type PriceLevel struct { Price decimal.Decimal Orders []*Order // FIFO queue Total decimal.Decimal // cached volume } type OrderBook struct { Bids *btree.BTree // descending (max bid first) Asks *btree.BTree // ascending (min ask first) mu sync.RWMutex } 

Выбор структуры данных критичен: Red-Black Tree (Go btree) — O(log n) insert/delete, Skip List — конкурентный доступ, Array + binary search — быстро на малых книгах. Для <10,000 active orders btree достаточно; при >100,000 и latency <100 мкс требуется более сложная архитектура. Согласно CME Globex Matching Algorithm, гибридные схемы обеспечивают наилучший баланс.

Алгоритм matching

Price-time priority (FIFO) — стандарт для большинства бирж:

func (ob *OrderBook) Match(incoming *Order) ([]Trade, *Order) { ob.mu.Lock() defer ob.mu.Unlock() var trades []Trade remaining := incoming.Quantity for remaining > 0 { bestLevel := ob.getBestOppositeLevel(incoming.Side) if bestLevel == nil { break } if !ob.priceMatches(incoming, bestLevel) { break } for len(bestLevel.Orders) > 0 && remaining > 0 { maker := bestLevel.Orders[0] fillQty := min(remaining, maker.RemainingQty) trade := Trade{ TakerOrderID: incoming.ID, MakerOrderID: maker.ID, Price: bestLevel.Price, Quantity: fillQty, Timestamp: time.Now().UnixNano(), } trades = append(trades, trade) remaining -= fillQty maker.RemainingQty -= fillQty if maker.RemainingQty == 0 { bestLevel.Orders = bestLevel.Orders[1:] } } if len(bestLevel.Orders) == 0 { ob.removeLevel(incoming.Side.Opposite(), bestLevel.Price) } } incoming.RemainingQty = remaining return trades, incoming } 

Для стандартной CEX выбираем FIFO. Pro-Rata усложняет реализацию и провоцирует спам мелкими ордерами.

Почему мы используем in-memory matching engine?

Matching engine работает в памяти — это даёт latency в единицы миллисекунд вместо десятков. База данных (PostgreSQL) используется только для персистентности: при старте сервер загружает все open ордера в память. Запись в БД — асинхронная, через очередь. Такой подход выдерживает 50,000–100,000 ордеров/сек на одном инстансе. Для масштабирования используем шардинг по торговым парам. Разработка собственного решения обходится в 3–5 раз дешевле ежегодной лицензии готового проприетарного движка.

Как защититься от race conditions при отмене и fill?

Перед размещением ордера резервируем средства: buy limit — price * quantity в quote, sell limit — quantity в base. При отмене освобождаем резерв. Atomicity обеспечивается через in-memory баланс с асинхронной синхронизацией в БД. В-памяти баланс — source of truth для торговли, БД — для персистентности и UI. Все операции с балансом выполняются под мьютексом, что предотвращает race conditions.

Модель данных

CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), user_id BIGINT NOT NULL REFERENCES users(id), pair_id SMALLINT NOT NULL, side SMALLINT NOT NULL, type SMALLINT NOT NULL, status SMALLINT NOT NULL DEFAULT 0, price NUMERIC(36,18), stop_price NUMERIC(36,18), quantity NUMERIC(36,18) NOT NULL, filled_qty NUMERIC(36,18) NOT NULL DEFAULT 0, time_in_force SMALLINT NOT NULL DEFAULT 0, expire_at TIMESTAMPTZ, client_order_id VARCHAR(64), created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE trades ( id BIGSERIAL PRIMARY KEY, pair_id SMALLINT NOT NULL, taker_order_id UUID NOT NULL, maker_order_id UUID NOT NULL, taker_user_id BIGINT NOT NULL, maker_user_id BIGINT NOT NULL, price NUMERIC(36,18) NOT NULL, quantity NUMERIC(36,18) NOT NULL, taker_fee NUMERIC(36,18) NOT NULL, maker_fee NUMERIC(36,18) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE INDEX idx_orders_user_status ON orders(user_id, status) WHERE status IN (0, 1); CREATE INDEX idx_orders_pair_side_price ON orders(pair_id, side, price) WHERE status IN (0, 1); 

Критичный момент: matching engine работает в памяти, БД — только для персистентности. Запись в БД асинхронная, через очередь.

Stop orders и триггерный механизм

Stop ордера хранятся в отдельной структуре — sorted по stop price. При каждой сделке matching engine публикует последнюю цену. Stop orders processor подписывается на price updates:

func (sp *StopProcessor) OnPriceUpdate(pair string, lastPrice decimal.Decimal) { triggeredBuys := sp.buyStops.GetTriggered(pair, lastPrice) triggeredSells := sp.sellStops.GetTriggered(pair, lastPrice) for _, stop := range append(triggeredBuys, triggeredSells...) { sp.activateStop(stop, lastPrice) } } 

Trailing stop — особый случай. При движении цены в пользу пользователя stop price пересчитывается. Реализация через event-driven пересчёт при каждом trade.

Decimal precision и floating point

Никогда не используйте float64 для финансовых расчётов. 0.1 + 0.2 != 0.3 в IEEE 754. Используем: Go — shopspring/decimal, Python — decimal.Decimal, Java — BigDecimal, JavaScript — decimal.js. Все хранимые значения — NUMERIC(36,18). Precision и scale задаются для каждой торговой пары отдельно (Bitcoin: 8 знаков, мем-коины: до 18).

Этапы реализации

1. Проектирование — анализ требований, выбор алгоритмов, моделирование потоков нагрузкой до 100 000 ордеров/сек.
2. Разработка — написание matching engine с нуля или на основе референсной архитектуры (Go, btree, decimal).
3. Интеграция — связь с PostgreSQL, настройка асинхронной записи и балансового модуля.
4. Тестирование — unit-тесты (покрытие >85%), property-based testing (fuzzing), нагрузочные тесты с замерами latency/throughput.
5. Деплой — развёртывание на инфраструктуре, мониторинг, обучение команды.

Что входит в работу

При заказе вы получаете:

• Архитектурную документацию matching engine и API спецификацию
• Репозиторий с исходным кодом (Go, production-ready)
• Набор unit-тестов и интеграционных тестов (покрытие >85%)
• Результаты нагрузочного тестирования с метриками latency/throughput
• Руководство по развертыванию и эксплуатации
• 2 месяца постпродакшн поддержки и обучения вашей команды

Тестирование

Matching engine покрывается unit-тестами на граничные случаи:

• Partial fill с остатком
• FOK при недостаточной ликвидности
• IOC с частичным исполнением
• Одновременная отмена и fill (race condition)
• Stop ордер триггерится в момент своего размещения
• Decimal overflow на крайних значениях

Property-based testing (fuzzing) — генерируются случайные последовательности ордеров, проверяется инвариант: суммарный объём купленного = суммарному объёму проданного, балансы сходятся.

Сроки разработки

• MVP (limit + market, без stop, без time-in-force): 3–4 недели
• Полная система с stop orders, всеми TIF модификаторами, trailing stop: 8–12 недель
• Production-ready с аудитом, нагрузочными тестами, мониторингом: +4–6 недель

Бюджет проекта рассчитывается индивидуально под ваши требования. Получите консультацию по вашему проекту — свяжитесь с нами для предварительной оценки. Также вы можете заказать аудит текущей архитектуры — мы предоставим отчёт с рекомендациями.