Модульный монолит против микросервисов в банковской архитектуре
Выбор между модульным монолитом и микросервисами в банке — не вопрос модности технологии, а вопрос операционной зрелости команды, состояния ядра и реального бизнес-потока. Эта статья разбирает, когда какой подход оправдан, какие архитектурные ошибки типичны для банков ЦА, и как избежать раздробления систем без бизнес-причины.
Обсудить задачуЭта архитектурная статья разбирает выбор между модульным монолитом и микросервисами в банковской системе с точки зрения операционной зрелости, состояния ядра и реальных бизнес-задач. Без модной технологии — с конкретным фазовым roadmap для банка Центральной Азии.
В чём архитектурный вызов
Большинство банков региона стоят перед архитектурным выбором: модернизировать существующий монолит АБС с его слоями интеграций или раздробить его на микросервисы. Решение чаще всего принимается под влиянием маркетинга вендоров и презентаций конференций, а не на основе анализа реального операционного потока, зрелости команды и бизнес-задач. Результат — десятки новых микросервисов, которые обслуживает команда, не готовая к их эксплуатации, или дальнейшее накопление функциональности в монолите, который становится узким местом по любому изменению.
Какие системы, потоки и команды вовлечены
- АБС (ядро банка) — Colvir, ЦФТ, OpenWay, SAP Banking — обычно крупный монолит
- Слой интеграций — ESB, API gateway, event bus
- Продуктовые системы — ДБО, мобильное приложение, кредитный конвейер, антифрод, ПОД/ФТ
- Команды разработки — численность, опыт DevOps, готовность к микросервисной операционной модели
- Инфраструктура — мощности, наблюдаемость, безопасность, SLA
Типичные архитектурные ошибки
- Раздробление системы на микросервисы по технологическому критерию (один сервис = одна таблица), не по бизнес-домену
- Старт с микросервисов до того, как команда умеет эксплуатировать их в проде — отсутствие observability, CI/CD, on-call
- Попытка одновременно заменить монолит АБС микросервисами — проект на 36+ месяцев с высокой вероятностью провала
- Сохранение монолитной АБС с обвешиванием десятками точечных интеграций без слоя — каждое изменение задевает 5+ систем
- Декларация «у нас микросервисы», а на самом деле — распределённый монолит с синхронной зависимостью между сервисами
- Микросервисы для команды из 5 разработчиков — операционная нагрузка превосходит выгоды
Возможные подходы
- Сохранить монолитную АБС, построить вокруг слой интеграций (event bus + API gateway), новые продукты — как отдельные модули или сервисы. Это путь большинства банков региона.
- Модульный монолит — единая система с чёткими границами модулей и явными интерфейсами. Хорошо подходит для команд 10-30 разработчиков.
- Микросервисы по бизнес-доменам (кредит, депозит, карты, ПОД/ФТ) — оправдано для крупного банка с командой 50+ разработчиков и зрелым DevOps
- Гибрид — монолитная АБС, микросервисный слой продуктов и каналов вокруг неё. Промежуточный путь для большинства.
Как обойтись без замены ядра
Замена ядра АБС — отдельное стратегическое решение, не предпосылка модернизации. Современные АБС поддерживают темп бизнеса при условии, что вокруг них построен слой интеграций. Стратегия strangler pattern — постепенно выносить функциональность из АБС в новые модули или сервисы по мере её устаревания, не заменяя всё одновременно. Это снижает риск программы в десятки раз и даёт измеримый эффект на каждой фазе.
Риски, зависимости, ограничения
- Готовность команды к микросервисной модели — главный риск. Без зрелого DevOps микросервисы становятся обузой
- Зависимость от наблюдаемости — без полноценного monitoring/tracing микросервисная архитектура неуправляема
- Операционные расходы микросервисов выше — больше инфраструктуры, больше команд, больше координации
- Безопасность распределённой системы сложнее — каждый сервис требует своих контролей доступа
- Регуляторные требования (ПОД/ФТ, отчётность) проще реализовать в монолите — нужна централизация контроля
Как выглядит фазовый путь
- Месяцы 1-3: диагностика текущей архитектуры, оценка зрелости команды, формулирование целевой модели
- Месяцы 4-9: построение слоя интеграций (event bus, API gateway), единого клиентского профиля, observability
- Месяцы 10-15: пилотный продуктовый блок (обычно ДБО или новый кредитный продукт) на новой архитектуре
- Месяцы 16-24: расширение по продуктовым блокам, постепенный вынос функций из АБС
- Решение о замене АБС — после 24-36 месяцев, когда понятно, что именно стало узким местом
Что ещё стоит изучить
Темы из этой же области, которые часто разбираем вместе с этой
CRM
Не коробочный CRM, а правильно выстроенный контур управления клиентами — от первого контакта до лояльности.
→РешениеBI
Аналитика — не красивые графики на стене. Это ответ на вопрос 'почему?' до того, как проблема станет убытком.
→РешениеКонтакт-центр
Контакт-центр — не телефонная станция, а точка, где клиент решает: остаться с вами или уйти. Вопрос в том, как он устроен внутри.
→РешениеОнбординг
Онбординг — первое впечатление клиента о вашей компании. Если оно занимает 5 дней и 12 бумажных форм, второго впечатления не будет.
→Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.
Обсудить применение →Готовы обсудить вашу задачу?
Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.
Обычно отвечаю в течение нескольких часов