Компании, которые пишут торговые платформы и matching engine на Rust: какие части нужны на Rust и как нанять выделенную команду

Ищите фирму, чьи собственные инженеры уже построили на Rust matching engine или другую часть пути заявки и поддерживают её в продакшене. До подписания познакомьтесь с людьми, которые войдут в вашу команду. Rust оправдывает себя там, где задержка стоит денег: matching engine, предторговые риск-проверки, шлюзы к биржам и обработчик рыночных данных. Экраны, отчёты и инструменты бэк-офиса могут остаться на тех языках, которые ваша компания уже использует.

Какие компании специализируются на торговых платформах и matching engine на Rust?

Эта статья не составляет рейтинг фирм. Специалист — это фирма, чьи собственные инженеры уже выпустили торговую систему на Rust и эксплуатируют её для клиента. Фирма, которая собирается нанимать инженеров на Rust после того, как вы подпишете договор, предлагает вам вместо этого план найма.

Торговый код часто закрыт: им обычно владеют клиенты и держат его у себя, поэтому у сильной фирмы может быть мало торгового кода на GitHub. Вместо этого попросите описать от начала до конца одну систему в продакшене: что она делает, какие части написаны на Rust, как измеряется её скорость, кто эксплуатирует её сегодня и что сломалось после запуска. Если имя клиента скрыто соглашением о конфиденциальности, попросите фирму организовать звонок с этим клиентом.

Затем проверьте людей. Узнайте имена и опыт на Rust инженеров, которые будут работать над вашей системой, и поговорите с ними до подписания. В статье о выделенных командах, ссылка на которую дана выше, разобраны общие проверки: публичный код, оплачиваемое пробное задание и ревью независимым инженером.

Какие части торговой платформы стоит писать на Rust?

Те, что лежат на пути заявки, где пауза в несколько миллисекунд может изменить цену, которую получит клиент:

• Matching engine, который сводит заявки на покупку и продажу по цене и времени поступления
• Предторговые риск-проверки, которые останавливают заявку, нарушающую лимит, до того как она уйдёт на рынок
• Шлюзы, которые отправляют заявки на биржи или брокерам и принимают их ответы
• Обработчик рыночных данных, который читает ценовые потоки и передаёт дальше каждое обновление

Rust подходит для этих частей, потому что освобождает память без сборщика мусора. В некоторых языках эту работу делает именно он, и он может приостановить программу в выбранный им самим момент. Книга о Rust (официальное руководство по языку, прочитано 27 октября 2026 года) говорит, что владение, то есть набор правил, на котором это держится, «позволяет Rust давать гарантии безопасности памяти без сборщика мусора».

Сам по себе язык не делает систему быстрой. Программа на Rust всё равно может остановиться, чтобы запросить память, подождать блокировку, которую держит другой поток, или подождать сеть. В статье о проектировании matching engine объясняется, как команда убирает всё это с пути заявки.

У остальной платформы нет срока, который измеряется миллисекундами: веб- и мобильные экраны, клиентские счета, отчёты, бэк-офис и инструменты администрирования. Они могут остаться на тех языках, которые уже используют ваши разработчики или поставщики. Фирма, которая предлагает переписать их на Rust, должна объяснить, что это вам даст.

Наша платформа уже работает на C++, Java или Go. Переписывать её на Rust?

Обычно не целиком и не сразу. Надёжнее перенести один компонент с чёткой границей, например риск-проверки или обработчик рыночных данных, а остальное оставить как есть.

Новый компонент может работать отдельным сервисом, который обменивается сообщениями с остальной системой. Его можно собрать и как библиотеку, которую напрямую вызывает код на C или C++. Rustonomicon, руководство проекта Rust по небезопасному и низкоуровневому коду, описывает, как это сделать, в разделе «Calling Rust code from C».

Перед переключением запустите новый компонент рядом со старым на одном и том же записанном потоке заявок и сравните каждый результат. Детерминированный matching engine всегда даёт один и тот же результат для одних и тех же заявок в одной и той же последовательности. Поэтому сравнение получается простым: если оба движка применяют одни и те же правила, любое расхождение указывает на ошибку в одном из них.

Затем переводите по одному рынку или по одной группе инструментов и держите старый компонент наготове, чтобы вернуть ему трафик.

Кто входит во внешнюю выделенную команду на Rust для matching engine?

Выделенная команда месяцами или годами работает только над вашей системой, а её состав меняется только с вашего согласия. Для matching engine или другой части пути заявки в неё обычно входят:

• Инженеры на Rust, которые выпускали код в продакшен и знают, как живёт заявка: типы заявок, частичные исполнения, изменения и отмены
• Ведущий инженер, который отвечает за архитектуру и проверяет каждое изменение на пути заявки
• Инженер по тестированию, который строит стенд для воспроизведения записанного потока заявок и проверяет результаты
• Человек, отвечающий за серверы, сетевые настройки и выпуск версий

Свою роль играет и ваша компания. Кто-то на вашей стороне определяет торговые правила, например шаг цены, часы торгов, комиссии и то, что происходит при остановке торгов, и без долгих задержек отвечает на вопросы команды о них.

Фрилансеры могут быть отличными инженерами, но с непрерывностью работы у них сложнее. У одиночного подрядчика нет никого, кто проверял бы изменения на пути заявки, а когда этот человек уходит, вместе с ним уходит и всё, что он знал о вашей системе. Фирма может заменить человека и сохранить знания в команде, и договор может её к этому обязать.

Фирма может оценить размер команды только после того, как увидит ваши торговые правила, рынки и объёмы, поэтому спросите, как она пришла к той цифре, которую называет.

Что спросить у команды на Rust о matching engine?

Как проверять заявленные показатели скорости, разобрано в статье о фирмах, которые делают системы с низкой задержкой. Эти вопросы — о Rust и о пути заявки:

• Где ваш код использует unsafe и кто проверяет эти места?
• Как вы тестируете движок, кроме воспроизведения записанных заявок?
• От каких крейтов зависит путь заявки и как вы проверяете их на известные уязвимости?
• С какой версией Rust вы собираете проект и как решаете, когда обновляться?
• Кто в предлагаемой команде уже выпускал Rust в продакшен, на какой системе и работает ли она до сих пор?

Rust проверяет, как используется память, ещё при компиляции кода. Внутри блока с пометкой unsafe код может делать пять вещей, которые компилятор иначе запрещает, например переходить по сырому указателю в память. Книга о Rust добавляет, что unsafe «не отключает borrow checker и не выключает другие проверки безопасности Rust». Хороший ответ называет, где находится небезопасный код, зачем он там нужен и кто его проверял.

Когда речь о тестировании, команда должна назвать инструменты, которыми пользуется. cargo-fuzz, который Rust Fuzz Book называет «рекомендуемым инструментом для фаззинг-тестирования кода на Rust», подаёт программе большие объёмы сгенерированных входных данных, чтобы найти случаи, на которых она падает. Loom, библиотека для тестирования кода, работающего в нескольких потоках, «запускает тесты много раз, перебирая возможные варианты параллельного выполнения каждого теста». Так находятся ошибки, которые проявляются только тогда, когда потоки выполняются в неудачном порядке.

Крейты — это пакеты общего кода в Rust. База RustSec Advisory Database собирает бюллетени безопасности для крейтов, опубликованных на crates.io. Её инструмент cargo-audit проверяет Cargo.lock проекта, файл со списком точных версий всех зависимостей, «на крейты с уязвимостями безопасности». Команда, которая работает над путём заявки, должна уметь сказать вам, запускается ли такая проверка при каждой сборке.

Новая стабильная версия Rust выходит каждые шесть недель, и книга о Rust говорит, что «вам никогда не придётся бояться перехода на новую стабильную версию Rust». Команда всё равно может держать все сборки на одной выбранной версии. Документация rustup, установщика Rust, описывает файл toolchain для проектов, которые оказываются «„привязаны“ к определённому релизу Rust» и хотят, чтобы это было записано в их репозитории. Для пути заявки версия должна меняться только намеренно, после того как пройдут тесты.

Что должно быть в договоре с командой на Rust?

Впишите в него такие пункты:

• Код, тесты, данные для воспроизведения и сборочные скрипты хранятся в репозиториях, которыми владеет ваша компания
• Сборки и выпуски идут в аккаунтах, открытых на имя вашей компании
• Кто может менять путь заявки и кто проверяет каждое изменение
• Часы, которые покрывает команда, и кто отвечает, если движок откажет вне этих часов
• Что вы получаете, если договор прекращается: документацию, доступы и время команды на передачу дел следующей

Где здесь место amBrain?

amBrain, который ведёт этот блог, описывает себя одной строкой: «amBrain — инженерная компания из Еревана, Армения: строим low latency торговые платформы, matching engine и системы real-time bidding на Rust». Ещё одна строка: «amBrain строит инфраструктуру алгоритмической торговли: исполнение заявок, рыночные данные и предторговый риск-контроль».

amBrain делает софт с 2019 года. О своей команде компания говорит так: «Команда до 40 человек, около 75% из них — сеньоры». Компания работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов».

Эта статья — не кейс, и работа для клиентов в ней не описывается. В ней не сказано, какие системы amBrain построил на Rust и для кого, и в ней нет цен, сроков или размеров команды amBrain. Если amBrain в вашем шорт-листе, задайте ему те же вопросы, что и любой другой фирме.