Рынки не присылают приглашения на встречу перед тем, как начать содрогаться. Внезапное снижение процентной ставки, неожиданный результат выборов или резкое обострение геополитической обстановки могут заставить цены на активы колебаться в течение нескольких секунд. Трейдеры бросаются к своим мониторам. Заявки на покупку и продажу копятся. Ваша инфраструктура должна поглощать этот шок, не запинаясь. Когда объемы возрастают в десять раз за считанные минуты, низкая скорость, сбои в исполнении ордеров и полные отказы системы — это не мелкие неудобства. Это убийцы доверия.
Создание торговой платформы, способной пережить такие моменты, означает принятие архитектурных решений на ранних этапах. Одной лишь грубой вычислительной мощности будет недостаточно, если архитектура хрупка. Вот как подойти к этой проблеме, не рассматривая волатильность как простой всплеск трафика.
Начните с облачной инфраструктуры, которая «дышит»
Статичное оборудование — ваш враг. Если вы выделяете серверы исходя из среднего ежедневного объема, вы утонете во время всплеска. Если вы выделяете ресурсы с расчетом на самый худший сценарий, вы будете сжигать деньги, простаивая на неиспользуемых машинах остальную часть года.
Облачная инфраструктура решает эту проблему с помощью автомасштабирования. Вычислительная мощность должна расти автоматически вместе со спросом. В спокойное утро вторника вы работаете в экономном режиме. Когда выходит отчет о занятости и поток ордеров утраивается, запускаются новые экземпляры (instances), чтобы разделить нагрузку. Ключ к успеху — настройка политик масштабирования, которые реагируют достаточно быстро. Устанавливайте пороги на основе глубины очереди запросов, загрузки CPU и пропускной способности сети, а не на основе догадок. Также распределяйте свою архитектуру по регионам. Трейдеры в разных часовых поясах не должны бороться за один и тот же пул вычислительных ресурсов, если в этом нет необходимости. Региональное резервирование поддерживает низкую задержку и обеспечивает резервный вариант, если один из дата-центров не справляется.
Разделите платформу на микросервисы
Запускать всё в одном массивном кодовом базисе — это всё равно что положить все яйца в одну корзину, а затем пуститься в спринт. В монолитном приложении утечка памяти в инструменте построения графиков портфеля может привести к краху движка исполнения ордеров. На волатильных рынках такая связанность недопустима.
Разбейте платформу на независимые сервисы. Обрабатывайте аутентификацию пользователей отдельно от сбора рыночных данных. Изолируйте исполнение ордеров от управления портфелем и обработки платежей. Когда один компонент сталкивается с высокой нагрузкой, вы можете масштабировать его, не беспокоя остальную часть системы. Например, если какая-то «мемная акция» становится вирусной и все хотят проверить её цену, ваш сервис рыночных данных может масштабироваться, в то время как кластер исполнения ордеров останется зарезервированным для реальных сделок. Команды могут внедрять исправления в платежный шлюз во вторник днем, не затрагивая матчинговый движок.
Такое разделение требует дисциплины. Вам нужны четкие API, надежные паттерны межсервисного взаимодействия и правила плавной деградации системы. Если графики портфеля подтормаживают во время всплеска — это раздражает. Если книга ордеров замирает — это катастрофа. Проектируйте систему с учетом изоляции сбоев с самого начала.
Создавайте систему для скорости без ущерба для точности
Низкая задержка (low latency) в электронной торговле — это не роскошь. Если ваши проверки валидации и рисков добавляют ненужную задержку, трейдеры упустят свои уровни. Платформа будет казаться неисправной, даже если она технически находится в сети.
Ордера должны проходить через валидацию и оценку рисков с минимальной задержкой. Это не означает, что можно срезать углы. Это означает проектирование проверок, которые вычислительно эффективны. Используйте in-memory data grids для проверки кредитных лимитов и позиций вместо того, чтобы делать запросы к реляционной базе данных на каждом тике. Проверяйте синтаксис ордера на уровне шлюза еще до того, как он достигнет матчингового движка. Запускайте правила борьбы с мошенничеством и комплаенс-правила параллельно, где это возможно.
Точность — это вторая, не подлежащая обсуждению часть уравнения. Скорость не должна идти в ущерб точности. Быстрое, но некорректное исполнение хуже, чем медленное. Ваша система должна поддерживать строгую