От REST к событиям: как ОТП Банк перестраивает архитектуру ради устойчивости
Интеграция банковских систем всегда была непростым процессом, но в последние годы задача стала особенно острой.
Рост числа продуктов и каналов, ускорение бизнес-циклов и давление со стороны конкурентов делают старые подходы все менее эффективными.
Клиенты ожидают мгновенных переводов, персонализированных сервисов и бесшовного взаимодействия в любой точке контакта. Чтобы это обеспечить, недостаточно просто добавлять новые модули и связки между ними. Чем сложнее становится инфраструктура, тем выше риск замедлений и сбоев. Именно поэтому в ОТП Банке мы решили пересмотреть архитектуру и показать, какие решения реально работают в условиях масштабирования. В материале разберём, почему классические методы интеграции (DBLink, REST) перестают справляться, и как переход к событийной модели позволяет строить цифровую экосистему, где данные становятся стратегическим активом.
Почему прошлые подходы перестают работать
Одним из первых вызовов при создании новой платформы дистанционного банковского обслуживания становится интеграция с бэкофисом и АБС. В нашем случае поставщик предлагал два классических варианта: DBLink и REST API. Но оба решения быстро показали ограничения, из-за которых их нельзя было использовать как основу для масштабируемой архитектуры.
DBLink команда отвергла сразу. Прямой доступ к базе критичной системы создаёт слишком сильную связность (tight coupling) и несёт серьёзные риски для безопасности и производительности. Этот путь для нас был закрыт ещё на старте. Оставался REST API, и именно он лёг в основу первой версии MVP. Однако уже на этапе роста нагрузки стало очевидно, что синхронная интеграция не выдерживает масштабирования и ведёт к серьёзным ограничениям.
- Масштабируемость здесь работает напрямую: чем больше клиентов, тем выше нагрузка на АБС. Уже при первой тысяче мигрированных пользователей мы столкнулись с отказами из-за перегрузки, система не выдерживала сотен запросов в секунду. Частично ситуацию спасало кэширование, но устранить проблему полностью этот метод не мог.
- Пользовательский опыт. Синхронная интеграция выстраивала длинную цепочку зависимостей. Если в норме АБС отвечала за 200–300 мс, то под нагрузкой отклик растягивался до 2–3 секунд. В результате клиентское приложение превращало это в 5–10 секунд ожидания. Для пользователя это критично: такая задержка воспринимается как сбой и напрямую ведёт к оттоку клиентов.
- Архитектурный антипаттерн. Внешне система напоминала микросервисную архитектуру, но на деле всё зависело от одной точки отказа АБС. Получался «распределённый монолит» (Distributed Monolith): слабая изоляция отказов, отсутствие независимого масштабирования и снижение общей надёжности ниже целевых показателей.
Все эти факторы показали, что стандартные решения хороши только для прототипа, но не для долгосрочной стратегии. Чтобы выйти на уровень реальной устойчивости и скорости, нужно было искать другую архитектурную модель.
Почему событийная модель
Начнём с того, что любая распределённая система строится на компромиссе. CAP-теорема (Consistency, Availability, Partition Tolerance) формулирует его максимально жёстко: одновременно можно гарантировать только два из трёх свойств. В связке ДБО и АБС мы имеем дело с распределённым кластером, где сеть по определению ненадёжна, значит, устойчивость к разделению (P) должна учитываться всегда. Остаётся выбор между согласованностью (C) и доступностью (A).
Синхронный REST-подход делает приоритетом согласованность. Система блокирует клиента и ждёт ответа от АБС, чтобы вернуть строго актуальные данные. Но вместе с этим мы жертвуем доступностью: если бэкофис перегружен или недоступен, клиент не получает ничего. Для ДБО приоритет другой. Нам важно отвечать пользователю мгновенно, даже если часть информации может быть слегка устаревшей. Такой принцип называют конечной согласованностью (Eventually Consistent): клиент работает без задержек, а система синхронизирует данные в фоне, когда АБС снова выходит на связь.
Эта логика и привела нас к выбору событийной архитектуры. Она позволяет поддерживать высокий уровень доступности, снижать нагрузку на критичные системы и строить масштабируемые сервисы.
Как мы подошли к решению в ОТП Банке
Логичным выбором для событийной архитектуры стала Apache Kafka. Для банка принципиально важно было развернуть её в строгом соответствии с зональной моделью безопасности: критичная АБС осталась в самом защищённом контуре, а сам кластер Kafka был развёрнут в промежуточной зоне, через которую проходят все взаимодействия с ДБО. Такой подход позволил обеспечить устойчивость и контролируемое разделение потоков данных.
Однако уже на первых этапах эксплуатации проявилась фундаментальная проблема: не все транзакции корректно превращались в события. Данные, которые обрабатывались приложением на стороне АБС напрямую и шли в обход API, не фиксировались в логах и, соответственно, не попадали в Kafka. В результате кэш ДБО расходился с реальным состоянием, что критично для финансовых сервисов.
Чтобы решить проблему консистентности, команда рассмотрела несколько вариантов: ручную пересинхронизацию данных через REST, полную регулярную инвалидцию кэша и загрузку свежих данных. Но оба подхода либо оказались слишком трудоёмкими, либо создавали чрезмерную нагрузку на АБС.
В итоге был выбран третий вариант — инвалидация кэша и загрузка через ETL в нерабочее время. Каждую ночь в низконагрузочное окно (например, с 2:00 до 5:00) запускается процесс на базе Apache Airflow. Он берёт «золотой снапшот» ключевых данных из реплики базы АБС, преобразует их в нужный формат и точечно обновляет кэш ДБО. Такой подход позволяет минимизировать нагрузку на основную систему и гарантирует актуальность данных на начало дня.
Но и у этого варианта есть свои ограничения. Расхождения, которые возникают в течение дня из-за прямых изменений в базе, исправляются только в следующем ночном цикле. Тем не менее для нас это стало разумным компромиссом: полноценный CDC в АБС невозможен по соображениям безопасности и ограничениям инфраструктуры, а ночной ETL остаётся рабочим и надёжным инструментом для борьбы с «серыми» операциями.
Ограничения архитектуры и меры обхода
Внедрение Kafka решило многие задачи интеграции, но оказалось, что использовать её повсеместно невозможно. В крупных системах остаются зоны, где действуют устоявшиеся практики. Так, CRM и MDM продолжали работать через REST или MQ: переход на кафку потребовал бы серьезных доработок систем и с учетом загруженного бэклога был невозможен.
При этом именно эти потоки данных требовали максимальной точности. Из CRM поступали полномочия и права доступа клиентов, а из MDM — персональные данные и реквизиты. Любое расхождение между источником и кэшем ДБО здесь недопустимо: ошибка грозила операционными рисками и репутационными потерями.
Чтобы сохранить консистентность, команда OTP проработала несколько вариантов. Среди них: гибридная синхронизация с REST-проверкой при входе клиента, использование встроенных механизмов MQ, сквозная нумерация сообщений и ежедневная полная выгрузка через ETL. Все решения имели свои ограничения: от перегрузки источников до сложности поддержки.
В итоге мы разработали комбинированную стратегию. Наш консьюмер MQ был спроектирован как идемпотентный и научился отслеживать последовательность сообщений. Если фиксировался пропуск, система не запускала полную пересинхронизацию, а выполняла точечный REST-запрос к источнику. Дополнительно мы внедрили фоновую валидацию для выборочной сверки данных. Такой подход позволил снизить нагрузку на системы-источники, минимизировать риски расхождений и обеспечить требуемый уровень надежности при работе с критически важными данными.
Итоги: сложность ради устойчивости
Опыт перехода от синхронных REST-вызовов к событийной модели показывает, что архитектуре современных банков нет простых решений. Каждое упрощение сегодня оборачивается рисками завтра. Событийный подход действительно сложнее и требует дополнительных усилий для поддержания консистентности, но именно он даёт гибкость и масштабируемость, без которых невозможно развивать цифровую экосистему.
Главное, что удалось достичь, — настоящая отказоустойчивость. Клиентский сервис остаётся доступным всегда, даже если синхронизация данных продолжается в фоне. Для пользователя это означает стабильную работу без сбоев, а для банка — возможность выстраивать архитектуру, где надежность встроена в саму основу системы.