Одна бизнес-операция часто нужна сразу нескольким системам. Заказ сохраняется в основной базе, но его изменения также нужны аналитике, поиску, CRM, antifraud или витрине данных.
Самый очевидный вариант — заставить приложение после записи в базу отправить те же данные ещё куда-то. Но тогда появляется двойная запись: база могла сохраниться, а второе действие — нет. Или наоборот.
Какую проблему мы решаем
Чем больше таких интеграций, тем больше основная бизнес-логика начинает отвечать за доставку данных во внешние системы.
Change Data Capture читает журнал изменений базы или другой надёжный источник транзакционных изменений и превращает эти изменения в поток.
Приложение выполняет свою основную обязанность — корректно записывает бизнес-состояние. CDC замечает, что строка была добавлена или изменена, и публикует это изменение для downstream-систем.
Что получает бизнес
Главная выгода — новые потребители данных можно подключать с меньшим вмешательством в критический транзакционный код.
Это снижает цену интеграций. Аналитическая инициатива или новый канал не обязаны каждый раз требовать изменения логики оформления заказа только ради того, чтобы получить копию данных.
CDC также помогает уменьшить риск двойной записи, когда бизнес-операция уже завершилась, а внешняя система о ней не узнала из-за краткого сбоя.
Для компании это означает более дешёвое повторное использование операционных данных. Но появляется новая зависимость: бизнес должен понимать допустимую задержку. Вторичная система обычно узнаёт об изменении чуть позже основной базы.
Что получает команда
Команда получает единый технический способ распространять изменения данных без множества самописных интеграций внутри каждого сервиса.
Появляется возможность переигрывать поток, строить новые проекции и подключать потребителей независимо.
Но схема базы становится частью интеграционного контракта сильнее, чем раньше. Неосторожное изменение таблицы может неожиданно затронуть потребителей CDC.
Что получает клиент
Клиент обычно не знает о CDC напрямую. Он замечает последствия: поиск надёжнее видит новые данные, аналитические статусы обновляются стабильнее, разные части продукта меньше расходятся из-за потерянной второй записи.
При этом возможна короткая задержка. Например, заказ уже создан, а отчёт или поиск увидит его через несколько секунд.
Чем мы за это платим
Нужна инфраструктура чтения журнала изменений, хранение смещений, мониторинг задержки и обработка повторов.
Получатели должны быть готовы к дубликатам, изменению схемы и тому, что события отражают структуру хранения, а не всегда удобный бизнес-контракт.
Если CDC использовать как универсальную замену продуманным доменным событиям, внутренние детали базы могут расползтись по всей компании.
Когда CDC не нужен
Если данных мало, потребитель один, а интеграция проста, обычный API или явное доменное событие может быть понятнее.
CDC особенно полезен, когда изменений много, потребителей несколько или нельзя надёжно поддерживать двойную запись из приложения.
Что стоит спросить перед решением
- Какие системы сегодня получают копии данных через двойную запись?
- Допустима ли задержка между основной базой и потребителем?
- Нужны ли потребителям технические изменения строк или бизнес-события?
- Как будем управлять изменениями схемы?
- Нужно ли уметь переигрывать историю для нового потребителя?
В итоге
Change Data Capture полезен там, где данные должны покидать основную базу надёжно, но бизнес-операция не должна становиться диспетчером всех внешних систем.
Для бизнеса это способ дешевле подключать новые сценарии к уже существующим данным, принимая цену асинхронности и более серьёзного управления схемами.