Какие особенности использования API в современной биржевой торговле? С какими трудностями в разработке сталкивается крупный брокер? Александр Волков, который возглавляет направление API ответил на все эти вопросы в нашем подкасте —
&t
КОМУ НУЖНА API Тинькофф Инвестиций?
Если делить аудиторию на сегменты, то это:
1. Внешние сервисы, которые позволяют клиентам создавать роботов, вести аналитику и рассчитывать доходность
2. Алготрейдеры, которые хотят автоматизировать свою работу intraday. Если клиент торгует на днях, неделях, то ему проще заявку выставить через мобильное приложение или веб-терминал
3. Люди, которые используют неэффективности рынка в моменте. Например, образовался большой spread между покупкой и продажей — у робота есть эта ценная бумага. Он может одновременно покупать и продавать + выполнять функции маркетмейкера.
Алгоритмические трейдеры — это физические и юридические лица, использующие программы для покупки и продажи активов автоматически.
ЧТО ВНУТРИ ВТОРОЙ ВЕРСИИ API?
Первая версия API у Тинькофф Инвестиций была веткой от существующей версии мобильного приложения и веб-терминала. Вторая версия хоть и была основана на gRPC, но все равно продолжала поддерживать запросы по REST-API.
Rest
Изначально, его использовали в первой версии. Вторую версию можно также использовать через Rest.
gRPC-веб
Позволяет осуществлять стриминг рыночных котировок для браузерных веб-приложений
gRPC
1. По контрактам можно на любом языке программирования сгенерировать необходимый программный код и подключить поддержку API
2. Хорошо поддерживает версионность:
— все поля пронумерованы
— старые поля будут поддерживаться при добавлении любого количества новых
3. Поддержка дедлайнов запроса
💡 Ситуация
Запрос исполняется очень долго, например, какой-то инцидент на бирже. У клиента стоит тайм-аут в 5 секунд. Запрос уходит на сервер и исполняется 10 секунд, а у клиента все те же 5 секунд.
Получается, клиент уже дропает соединение, а мы продолжаем его исполнять. Важно учитывать, что внутри Тинькофф Инвестиций много сервисов, поэтому путь запроса нетривиальный. В итоге, один сервис может сделать запрос в другой сервис, в третий и так далее, а клиенту ответ уже не нужен.
В случае с gRPC мы задаем время, в течение которого запрос должен исполнится — дедлайн. Если дедлайн нарушен, то мы прерываем дальнейшую обработку, как и клиент.
ПОЧЕМУ ИСПОЛЬЗОВАЛИ gRPC, А НЕ ВЕБ-СОКЕТЫ?
Использование gRPC имеет несколько плюсов:
— современность
— производительность
— бинарность
💡 Основная причина использования gRPC — объединить сервисы, которые обеспечивают трансляцию веб-сокетов и сервисы, которые обеспечивают персональную обработку единичных запросов. И упаковать все в один канал.
ЧТО С БАЗОЙ ДАННЫХ? ПРОСЛОЙКА ИЛИЛ ЛОКАЛЬНАЯ БАЗА?
Направление API в Тинькофф Инвестициях ближе к прослойке.
Однако, есть задачи по рейтлимитированию — ограничению потока запросов, которое идет от каждого конкретного пользователя. Или логированию. Для них мы используем Postgres внутри нашей команды.
Все остальные запросы проксируются дальше во внутренние сервисы инвеста.
ПРОЕКТ В ЦИФРАХ
Обычно у нас около 1 млн. ордеров в день. Если говорить про пиковые значения, то доходит до 20 000 запросов в секунду.
ПЛАТНЫЙ ИЛИ БЕСЛПАТНЫЙ СЕРВИС?
В основном API бесплатная, но мы придерживаемся тактики динамичного лимитирования, исходя из торговой активности клиента.
Мы столкнулись с проблемой, что клиенты сильно грузили бэкэнд. Если клиент исполняет много ордеров и приносит много комиссий, то и лимиты будут очень большие. А если клиент торугет мало или вообще не торгует, то у него будут стандартные лимиты по ордерам.
Чем больше клиент торгует, тем больше ему позволяется делать запросов
КАК ПОСТРОЕНО КЕШИРОВАНИЕ?
У нас есть два типа кэша:
1. Redis
2. Кэш по торговым статусам — используется для сервисов, которым критически важна скорость уведомления пользователей о любых рыночных событиях.
БАЛАНСИРОВЩИК: NGINXИ САМОПИСНЫЙ СЕРВИС?
Мы используем первичный балансировщик invoya. На них же прикручены рейтлимитеры.
В 2022 было много DDoS-атак. Причем, не конкретно по API — по нему доставляют проблемы только отдельно взбесившиеся роботы. Обычно DDoS подвергается вся структура банка и мы получаем за компанию.
ЧТО ТАКОЕ ВЗБЕСИВШИЙСЯ РОБОТ? ТЕРЯЮТ ЛИ ЛЮДИ ДЕНЬГИ ИЗ-ЗА НИХ?
Здесь важно понять сам процесс. Бывают такие ситуации:
💡 Заявка приходит на API — проходит проверку у брокера на достаточность средств — указанная сумма резервируется и блокируется на счете — после этого отправляется на биржу.
Если лимиты пересчитываются долго, то происходит такая ситуация:
💡 Ордер исполняется, а позиция до сих не обновилась. Робот думает, что позицию нужно докупить или продать, хотя по факту она уже исполнена. Таким образом, “ломается” стратегия клиента использующего робота: он может случайно закупить или продать лишних позиций, что особенно опасно при торговле с плечем. В конечном счете череда таких ошибок может привести к потере портвеля (Margin Call).
СТЕК
Мы используем много языков, но в основном Java. Раньше использовали GO, но решили отказаться от него. Не было какой-то принципиально технической причины или проблемы — получилось, что спецов, работающих на этом языке, проще найти на рынке.
КАК БОРЕТЕСЬ С ФРОДОМ?
С фродом боремся не столько мы, сколько биржа. Они сами настраивают антифродовские механики и сами потом блокируют клиентов. Мы, к сожалению, не можем влиять на этот процесс.
КАК ВЫ ИЗМЕРЯЕТЕ УДОВЛЕТВОРЕННОСТЬ ЮЗЕРОВ?
— Смотрим на количество сбоев
— Смотрим на время исполнения ордеров
— И проводим обычный кастдев: нравится или не нравится подукт? И так далее
Как правило, всем довольны 20-25% пользователей.
ГЛАВНАЯ ПРОБЛЕМА API В ТИНЬКОФФ ИНВЕСТИЦИЯХ
В подкасте мы говорили об этом, поэтому ответ можно посмотреть здесь —
&t
Но опытным читателям предлагаем пофантазировать: с какими сложностями архитектуры столкнулся Александр и его команда? Пишите в комментариях