Однопоточная архитектура в сочетании с Raft обеспечивает детерминизм и отказоустойчивость в биржевых системах. Это критично, когда цена ошибки измеряется не latency, а прямыми финансовыми потерями.
Проблема в биржевой архитектуре проявляется, когда система сталкивается с несоответствием между скоростью и предсказуемостью. Требования противоречивы: субмиллисекундная задержка (latency), строгая справедливость исполнения и возможность восстановить состояние рынка на любой момент времени. Любая недетерминированность ломает воспроизводимость. А без неё невозможно ни аудит, ни точный разбор инцидентов. Попытка распараллелить обработку ордеров усиливает throughput, но вводит гонки и делает поведение системы зависимым от таймингов.
В качестве решения выбирается single-threaded architecture для ядра матчинг-движка. Это сознательный отказ от параллелизма в критической секции. Все входные события обрабатываются строго последовательно. Такой подход упрощает модель: одинаковые входные данные всегда дают одинаковый результат. Для отказоустойчивости и доступности поверх этого добавляется Raft consensus. Он реплицирует журнал операций между узлами и гарантирует согласованное состояние. Trade-off очевиден: ограничение на масштабирование по CPU против сильной детерминированности и простоты reasoning о системе.
Ключевой принцип — детерминизм (determinism). Он позволяет реализовать несколько важных свойств:
- воспроизведение production-инцидентов через replay логов,
- zero-downtime rolling deployments за счёт идентичного поведения версий,
- точное восстановление состояния рынка на произвольный момент.
Функциональная модель биржи упрощается до базовых правил, например price-time priority. Это компактная формализация сложного поведения. Она определяет, какой ордер исполняется первым при пересечении цен. Важно, что такие правила легко кодируются в последовательной модели и сложно — в конкурентной.
Реализация начинается не с оптимизаций, а с построения тестового harness. Система рассматривается как чёрный ящик: входные API-действия, внутреннее состояние книги ордеров и выходные события. Такой подход фиксирует ожидаемое поведение до оптимизации. Далее ядро матчинг-логики изолируется и минимизируется. Чем меньше кода в критическом пути, тем легче гарантировать его детерминизм.
Сложности появляются на границе с внешним миром. Биржа — это не только матчинг, но и широковещательная доставка состояния участникам, хранение истории и соблюдение регуляторных требований. Например, необходимо уметь восстановить состояние рынка на уровне микросекунд за годы. Это требует строгой персистентности всех подтверждённых событий и согласованности реплик. Здесь Raft закрывает проблему консистентности, но добавляет накладные расходы на координацию.
Отдельное внимание уделяется latency-распределению. Важно не только среднее значение, но и хвосты (P99). Участники рынка строят стратегии с учётом этих характеристик. Непредсказуемые задержки приводят к финансовым потерям. Последовательная модель помогает “пригладить” хвосты, так как убирает вариативность, связанную с конкуренцией потоков.
Результат такого подхода — система, где поведение предсказуемо и воспроизводимо. Это позволяет:
- поддерживать 24/7 доступность через репликацию,
- проводить безопасные деплои без остановки,
- точно анализировать любые инциденты.
При этом в исходных данных нет конкретных метрик по latency или throughput. Но архитектурный выбор явно направлен на баланс: минимальная сложность ядра против масштабируемости за счёт горизонтального распределения через консенсус.
Подобные решения давно обсуждаются в индустрии финансовых систем. Здесь они доведены до логического предела: лучше пожертвовать параллелизмом, чем потерять контроль над системой. В контексте highload это выглядит контринтуитивно, но именно детерминизм становится базой для надёжности.