Миграция банковского ядра на собственную разработку. Как выстроить процессы распространения данных?

Архитектуры и масштабируемость

Тезисы

Стандартная картина: у банка есть АБС (автоматизированная банковская система, ядро банка), которая процессит все сделки/счета/проводки организации. Обычно это монолитное, зачастую вендорское решение.

Агрегированные данные ядра нужны всем, начиная от регуляторной отчетности и заканчивая продуктовой аналитикой. Где-то достаточно актуальности «за вчера», где-то данные нужны онлайн.

Обычная практика — репликация данных в хранилища + API АБС (к сожалению, зачастую используются также прямые интеграции с БД АБС). Но что, если банк решил написать собственное ядро на базе микросервисной архитектуры? Что, если данные теперь не живут в одном месте, а сервисы разрабатываются разными командами, и в них могут различаться подходы к разработке и модели данных?

Запросы потребителей при этом тоже растут — кто-то готов остаться на хранилищах (но при этом ожидает единообразие в модели данных), кто-то хотел бы получать онлайн-данные по запросу, а часть процессов заинтересована в событийной модели и хотела бы получать обновления в виде сообщений.

В рамках доклада будут разобраны следующие темы:
* АБС Райфа и основные типы бизнес-процессов потребления данных;
* что меняется во время миграции на новое ядро;
* как можно выстроить архитектуру распространения данных.