Разработка системы ордеров (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, гибридные схемы обеспечивают наилучший баланс.
| Структура данных | O-нотация | Конкурентность | Применимость |
|---|---|---|---|
| B-tree (Go btree) | O(log n) | RWLock | <100k orders |
| Skip List | O(log n) avg | Lock-free | >100k orders, high concurrency |
| Array + Binary Search | O(log n) search, O(n) insert | Lock per operation | Small order books, <1k |
Алгоритм 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
}
| Алгоритм | Применение | Особенности |
|---|---|---|
| FIFO (Price-Time) | Большинство CEX | Простой, справедливый |
| Pro-Rata | Фьючерсы (CME) | Крупные ордера получают приоритет |
| FIFO + Pro-Rata | ICE, Euronext | Гибридный |
| Uniform Price (Batch) | DEX, аукционы | Все сделки по одной цене |
Для стандартной 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.
Детали реализации trailing stop
Trailing stop — динамический стоп-ордер, чья триггерная цена следует за рынком с фиксированным отступом. Алгоритм: при каждом обновлении цены, если цена движется в сторону клиента, стоп-цена пересчитывается: new_stop_price = current_market_price - distance для sell trailing stop. При обратном движении (напротив клиента) стоп-цена не меняется, что позволяет зафиксировать прибыль. В реализации мы используем priority queue по stop_price, обновляемую при каждом 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).
Этапы реализации
- Проектирование — анализ требований, выбор алгоритмов, моделирование потоков нагрузкой до 100 000 ордеров/сек.
- Разработка — написание matching engine с нуля или на основе референсной архитектуры (Go, btree, decimal).
- Интеграция — связь с PostgreSQL, настройка асинхронной записи и балансового модуля.
- Тестирование — unit-тесты (покрытие >85%), property-based testing (fuzzing), нагрузочные тесты с замерами latency/throughput.
- Деплой — развёртывание на инфраструктуре, мониторинг, обучение команды.
Что входит в работу
При заказе вы получаете:
- Архитектурную документацию 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 недель
Бюджет проекта рассчитывается индивидуально под ваши требования. Получите консультацию по вашему проекту — свяжитесь с нами для предварительной оценки. Также вы можете заказать аудит текущей архитектуры — мы предоставим отчёт с рекомендациями.