В последнее время всё чаще сталкиваюсь с тем, что команды путают Event Sourcing и Change Data Capture (CDC) или пытаются использовать их как взаимозаменяемые штуки. На деле это два разных подхода с разными trade-offs. Event Sourcing — это когда ты хранишь всю историю изменений как последовательность событий, а состояние — это просто снэпшот. CDC же тупо ловит изменения в базе (например, из WAL PostgreSQL) и пушит их в Kafka.
У меня тут на проекте возникла дилемма: нужно построить систему аудита и аналитики, но при этом не перегружать основной сервис. Event Sourcing даёт полную историю и легкость воспроизведения состояния, но требует переписывания всей бизнес-логики. CDC — это «бесплатный» сыр: просто включаешь Debezium и получаешь стрим изменений, но теряешь контекст — например, не видишь, почему произошло изменение, только факт.
Кто-то пробовал комбинировать эти подходы? Или есть мнение, что CDC — это костыль для тех, кто не умеет в Event Sourcing? Интересно услышать реальный опыт, а не теоретические выкладки из блогов.
👍 1
Сравнивать Event Sourcing и CDC как взаимоисключающие подходы — методологическая ошибка. Это разные уровни абстракции. Event Sourcing — архитектурный паттерн для доменной модели, где событие — бизнес-факт. CDC — инфраструктурный механизм репликации данных на уровне строк. Их комбинируют, когда нужен audit trail без переписывания legacy: ES для core-доменов, CDC для сбора "сырых" данных в аналитику.
CDC не костыль, а прагматичный выбор. На проекте с аудитом и аналитикой без CDC вы утонете в поддержке снэпшотов и идемпотентности consumer'ов для недоменных данных. ES оправдан там, где важна воспроизводимость состояния и бизнес-логика завязана на последовательности событий (например, в системах с агрегатами). Для пассивной аналитики ES — оверинжиниринг.
Event Sourcing и CDC — это инструменты под разные задачи, а не конкуренты. На проекте с аудитом и аналитикой их комбинируют чаще, чем кажется: ES для core-доменов, где важна бизнес-логика и воспроизводимость, CDC — для сбора "сырых" данных из реплик или WAL без переписывания legacy. Debezium с Kafka Connect — стандартный стек для второго, если не нужен контекст мутаций.
Смешивать их в одном сервисе — риск. CDC даёт линейность изменений строк, но теряет семантику событий: не видно, почему запись изменилась, только что. Для аналитики это часто ок, для аудита с требованиями к полной истории — нет. Если нужно и то, и другое, проще разделить: ES для воспроизведения состояния, CDC для пассивного стрима в Data Lake. Иначе consumer'ы захлебнутся в идемпотентности.
