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

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