В современном финтехе скорость, надежность и глубина предоставляемой информации особенно важны. За интуитивно понятным интерфейсом, который видит трейдер, скрывается сложная архитектура из взаимосвязанных сервисов, отвечающих за сбор, обработку и доставку рыночных данных в реальном времени. Мы — команда MarketData компании «Финам», в этой статье мы рассказываем, как устроена наша система изнутри.
Интерфейс пользователя: модульный конструктор для трейдера
Финансовый терминал — это не монолитное приложение, а набор независимых блоков-виджетов, которые пользователь может настраивать под свои задачи. Вот некоторые из модулей, которые видит трейдер:
список котировок: центральный блок, где отображаются выбранные инструменты (акции, облигации, фьючерсы) с текущей ценой, изменением за день и миниатюрным графиком для быстрой оценки тренда;
блок технического анализа: мощный инструмент для глубокого анализа. Позволяет строить детальные графики с историей торгов в различных масштабах — от минутных свечей до многолетних тенденций;
общая информация об инструменте: справочный блок с ключевыми данными: тип актива, капитализация, параметры обращения и другая фундаментальная информация;
ход торгов: статистика текущей торговой сессии: экстремумы (максимумы и минимумы), объемы сделок и другие ключевые метрики дня;
«стакан цен» (Order Book): окно в рыночную ликвидность. Показывает заявки всех участников рынка: покупателей (готовых купить по определенной цене) и продавцов (предлагающих свою цену). Это ключевой инструмент для оценки текущего настроения рынка;
портфель: персональный раздел трейдера. Здесь отображается текущее состояние счетов, список активов, средняя цена приобретения и история сделок.
Важная особенность — возможность кастомизации. Пользователь может создавать и сохранять несколько рабочих пространств (например, «Активная торговля» с десятком «стаканов» или «Долгосрочные инвестиции» с графиками и новостями), быстро переключаясь между ними.
Архитектура под капотом: команды и взаимодействие
За каждым элементом интерфейса стоит отдельная команда разработки, отвечающая за свой сегмент данных:
команда рыночных данных (MarketData): отвечает за доставку биржевых рыночных данных в реальном времени. Их главная задача — обеспечить минимальную задержку между появлением данных на бирже и их отображением в терминале клиента. Это критически важно для стаканов цен, где «вкусные» объемы могут быть разобраны за доли секунды;
команда технического анализа: обеспечивает работу графиков и исторических данных. Обрабатывает огромные массивы информации, позволяя строить и масштабировать графики за любой период;
команда торговой интеграции: управляет ядром терминала — процессом выставления и обработки заявок. Отвечает за скорость исполнения ордеров и доставку статусов по сделкам и портфелю;
команда справочной информации: решает нетривиальную задачу по сбору, версионированию и хранению фундаментальных данных по десяткам миллионов инструментов из множества внешних источников и вендоров. Также обрабатывает корпоративные события (сплиты, дивиденды, делистинг).
Фронтенд-приложение (веб- или мобильное) взаимодействует с этими бэкенд-командами по принципу «запрос-ответ или подписка». Внутри бэкенда команды также обмениваются данными: например, сервис технического анализа может запрашивать исторические данные, а торговой бэк использует актуальные биржевые данные и справочную информацию по бумагам и эмитентам.
Технологический стек: скорость и надежность
Для решения своих задач команды используют современный, но проверенный стек технологий.
Языки программирования: основная нагрузка лежит на C++ (стандарты 17/20) с использованием библиотек Boost и STL для максимальной производительности. Для новых сервисов активно применяется Rust как язык, обеспечивающий высокую скорость и безопасность памяти. Python используется для вспомогательных задач и скриптования.
Коммуникация: внутренним стандартом обмена данными является система удалённого вызова процедур (RPC) с открытым исходным кодом, разработанная в Google в 2015 году. Это позволяет добиться высокой скорости и эффективности передачи данных между сервисами.
Шина данных: Apache Kafka используется как центральная шина для асинхронного обмена сообщениями.
Инфраструктура: HashiCorp Consul применяется для service discovery, чтобы сервисы динамически находили друг друга без привязки к IP-адресам. Мониторинг и алертинг построены на Prometheus и Grafana.
Вендорские интеграции: одна из ключевых сложностей — работа с протоколами внешних поставщиков данных (биржи, данные). Команды разрабатывают адаптеры, которые преобразуют нативные, зачастую уникальные протоколы вендоров в единый внутренний стандарт. Это позволяет изолировать сложность и работать внутри системы с согласованным форматом данных.
Главные вызовы и как мы их решаем
Работа в режиме реального времени с финансовыми данными накладывает уникальные требования:
Скорость обработки данных. Необходимо обрабатывать десятки тысяч событий в секунду с минимальной задержкой.
Решение: использование высокопроизводительных языков (C++, Rust), эффективных бинарных протоколов (gRPC/Protobuf) и оптимизированных внутренних структур данных, минимизирующих блокировки (по аналогии с паттерном Disruptor).
Огромные объемы данных. Система работает с данными по более чем 47,7 млн инструментов. В пиковые моменты (открытие/закрытие торговых сессий) нагрузка многократно возрастает.
Решение: Горизонтальное масштабирование сервисов, активное использование кэширования и построение отказоустойчивой архитектуры.
Отказоустойчивость и надежность: для финансового продукта простои недопустимы.
Решение: Все критические сервисы работают в режиме горячего резерва (N+1). Каждая нода рассчитана на двойную нагрузку на случай отказа соседа. Сквозной мониторинг времени доставки данных от вендора до клиента с помощью Prometheus и Grafana позволяет сразу выявлять и устранять узкие места.
Оптимизация трафика: активные биржи (например, криптовалютные) генерируют колоссальный трафик. Стоит задача найти баланс между скоростью доставки данных и стоимостью использования трансатлантических каналов связи.
Решение: Поиск компромиссов и внедрение алгоритмов сжатия и оптимизации передачи данных.
Взгляд в будущее: планы развития
Архитектура постоянно развивается. Среди ключевых задач на ближайшую перспективу:
упрощение архитектуры: активное внедрение Apache Kafka как единой шины данных для всех сервисов. Это позволит упростить взаимодействие между командами, повысить надежность и упростить процедуры восстановления после сбоев;
повышение эффективности: постоянная работа над оптимизацией потребления памяти и производительности сервисов, особенно в свете растущего количества инструментов и запросов;
готовность к любым сценариям: разработка и отработка планов аварийного восстановления (Disaster Recovery), позволяющих развернуть всю систему с нуля в кратчайшие сроки.
За внешней простотой финансового терминала скрывается сложный и высоконагруженный организм. Бесперебойная работа этого механизма обеспечивается слаженной работой команд, современными технологиями и постоянной работой над выявлением и преодолением новых вызовов.
Хочешь решать такие же интересные задачи? Загляни на наш сайт, чтобы узнать больше о компании и открытых позициях в IT-департаменте «Финама». Мы всегда рады талантливым разработчикам, которым интересны сложные задачи и работа в финтехе.
