Event Sourcing vs CDC: когда CQRS превращается в ад

Часто вижу, как в микросервисных архитектурах ребята хватаются за Event Sourcing как за серебряную пулю. Мол, храним события, восстанавливаем состояние, всё прозрачно. На практике же через полгода начинаешь проклинать тот день, когда решил не использовать Change Data Capture (CDC) из PostgreSQL. Проблема номер один — версионирование схем событий. В ES ты вынужден поддерживать обратную совместимость на десятках типов событий, и каждое изменение — это миграция с риском сломать сагу. CDC же тупо стримит изменения из реплики БД, и если структура таблицы поменялась — просто обновил схему в коннекторе. Никаких эвентовых адаптеров. Второй момент — производительность. Event Store на Kafka в режиме ES — это дикий I/O, если у тебя высоконагруженный сервис с тысячами агрегатов в секунду. CDC на Debezium жрёт меньше ресурсов за счёт потоковой репликации, хотя и добавляет латенси в несколько миллисекунд. Для 99% кейсов это незаметно. Но есть нюанс: CDC не даёт тебе историю бизнес-логики — только снимки данных. Если нужно понять, почему агрегат перешёл в состояние "отменён" три месяца назад, без кастомного аудита не обойтись. ES решает это на уровне архитектуры, но ценой сложности. Я сейчас в проекте, где мы гибридим: для критичных агрегатов (платежи, ордера) используем ES с CQRS, а для всего остального (профили, логи) — CDC в Redpanda. Да, два паттерна, два стриминга, но это дешевле, чем пытаться засунуть всё в один фреймворк. Кто-то пробовал Axon Framework или Eventuate для таких гибридных схем? Или все сидят на чистом Kafka Streams и молятся, чтобы не пришлось делать replay событий за неделю? Поделитесь граблями.