Как перевести банковский продукт в real-time

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

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

Звучит как техническая замена batch на stream processing. На практике меняются архитектура, процессы команды и договорённости с бизнесом.

Архитектура раннего продукта

Базовый поток выглядел так:

1. событие клиента поступает в Kafka;
2. Apache Flink обрабатывает поток и запрашивает данные для обогащения;
3. Tarantool хранит оперативные профили и справочники;
4. бизнес-правила формируют решение;
5. результат возвращается через Kafka в целевой канал.

PostgreSQL использовался для данных и сценариев, которым не требовалась скорость in-memory хранилища. Такое разделение позволяло не превращать каждый компонент в универсальный инструмент.

Что обнаружилось между контурами

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

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

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

Хронология без смешения проектов

Ниже — моя уточнённая хронология участия; она отделяет два проекта и не является независимым отчётом об их приёмке. Работа над ранним real-time продуктом началась в октябре 2023 года. Основную команду собрали примерно за два месяца. В конце декабря и январе проверяли технический прототип, в феврале — бизнес-сценарий.

В марте требования изменились, и команда подготовила обновлённую версию примерно за месяц. В апреле решение вышло в промышленную эксплуатацию; к июню 2024 года мы продолжили его расширение.

Новый Decision Engine / SAS RTDM — другой проект. Я пришёл в него в конце сентября 2024 года, а разработка шла с декабря 2024 по апрель 2025 года.

Что здесь важнее технологий

Контракты между командами. Потоковая система чувствительна к изменению схем, задержкам источников и различию трактовок одного события. У каждого контракта должен быть владелец.

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

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

Общие решения с бизнесом. Real-time не является ценностью сам по себе. Он оправдан там, где своевременность действительно меняет клиентский сценарий или экономику продукта.

Главный урок этого проекта не в выборе Flink, Kafka или Tarantool. Он в том, что скорость реакции системы начинается с качества инженерных и управленческих договорённостей.

Как проверить, нужен ли бизнесу realtime

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

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

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

Что я включил бы в проверку перед запуском

Ситуация	Вопрос к системе
Событие пришло повторно	Будет ли бизнес-действие выполнено второй раз?
События поменялись местами	Как определяется актуальное состояние?
Профиль обновился с задержкой	Можно ли принимать решение на старом контексте?
Канал временно недоступен	Где хранится результат и когда он теряет смысл?
Правило изменилось	Можно ли объяснить, какая версия дала результат?

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

Для руководителя здесь существенна вся цепочка: от экономического смысла своевременного решения до реакции дежурной команды на остановившийся поток. Именно на этой границе продуктовая цель превращается в инженерную ответственность.

---

Расширенная история проекта опубликована на Habr. По этому же кейсу мы выступили на Saint HighLoad++ 2024 в Санкт-Петербурге.

Ваш ДПУПП