Saint HighLoad++ 2024: опыт перевода банковского продукта в real-time

24 июня 2024 года мы с Владимиром Аврамовым выступили на Saint HighLoad++ в Санкт-Петербурге с докладом «Опыт перевода банковского продукта в риалтайм».

Доклад относится к раннему real-time продукту, начатому в октябре 2023 года. Это не новый Decision Engine / SAS RTDM, к которому я присоединился в конце сентября 2024 года.

В одном докладе нужно было объяснить путь от пакетной обработки к реакции на события клиента. Мы сознательно не пытались пересказать весь проект. Оставили три вопроса: зачем бизнесу real-time, как был устроен поток данных и какие ограничения проявились при проверке архитектуры.

Схема, которую можно объяснить

В основе решения были Kafka, Apache Flink, Tarantool и PostgreSQL. Событие клиента поступало в Kafka, обрабатывалось во Flink, обогащалось оперативными данными и передавалось дальше вместе с результатом бизнес-правил.

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

Что мы рассказали про Tarantool

При переходе между средами проявились различия конфигураций, а при функциональной проверке — ошибка обработки сложного запроса в модуле CRUD Tarantool. В разборе доклада у организатора эти ситуации описаны отдельно. Интеграцию пришлось менять, часть логики — переносить во внешние сервисы. Tarantool при этом остался в архитектуре.

Для нас важнее самой ошибки были два вывода:

1. нужно проверять совместимость сред и корректность запросов; нагрузочные проверки дополняют эти проверки, но не заменяют их;
2. критическая технология не должна зависеть от знаний одного специалиста.

Такой рассказ полезнее истории о безошибочном выборе стека. Он показывает не только финальную схему, но и способ принятия решения.

Почему мы выступали вдвоём

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

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

Что я забрал из подготовки

Хороший технический доклад не должен превращать внутренний проект в рекламу. Его задача — показать контекст, решение, ограничения и выводы, которые слушатель сможет проверить на своём опыте.

И ещё одна полезная граница: не вся точность уместна публично. Архитектурный принцип можно раскрыть, не публикуя внутреннюю нагрузку, бизнес-метрики и устройство защищённого контура.

---

Страница доклада в программе Saint HighLoad++ 2024.

Ваш ДПУПП