Когда Event Sourcing и полный CQRS применять не стоит, и что делать вместо этого?
- Когда не стоит применять Event Sourcing?
- Как внедрять CQRS постепенно?
Не нужно в CRUD-домене, при требовании немедленной согласованности и без опыта эксплуатации асинхронных конвейеров. Вводить по нарастающей и точечно.
- Цена: версионирование событий навсегда, отставание проекций, тяжёлая отладка расхождений, удаление персональных данных
- Оправдано, где история — бизнес-требование: деньги, учёт, аудит, сложные процессы
- Путь: простой CQRS в приложении → отдельная модель чтения → event sourcing для одного контекста
А ещё Аудит-таблица часто закрывает потребность в истории без event sourcing
Подробно
Вопрос про инженерную зрелость: ответ «зависит» не годится, нужны конкретные условия и цена.
Когда не стоит:
- CRUD-домен — данные в основном создаются и редактируются формами без сложных правил: справочники, профили, контент. Журнал событий добавит сложность без выгоды;
- нужна немедленная согласованность чтения после записи во многих сценариях — асинхронные проекции будут постоянно мешать;
- команда без опыта эксплуатации асинхронных конвейеров, брокеров, перестроения проекций;
- сильные требования к удалению данных без готовности к крипто-шреддингу.
Цена, о которой забывают: версионирование событий — постоянная работа; проекции отстают и иногда расходятся с журналом, отладка таких расхождений тяжела; запросы по текущему состоянию требуют проекций; миграции превращаются в апкастинг.
Когда оправдано: история и аудит — бизнес-требование (финансы, учёт, страхование), нужно восстановление состояния на момент, сложные процессы с множеством реакций на события.
Как вводить: сначала простой CQRS внутри приложения; если нужно — отдельная модель чтения через outbox или CDC; event sourcing — только для отдельного ограниченного контекста, где он окупается, а не для всей системы. Часто историю закрывает обычная аудит-таблица или журнал изменений.
Что хотят услышать
- Конкретные условия, когда не применять.
- Конкретная цена, а не общие слова о сложности.
- Где оправдано.
- Постепенный и точечный путь внедрения, альтернативы.
Частые ошибки
- Применять event sourcing ко всей системе сразу.
- Не называть цену версионирования.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Никогда — event sourcing устаревший подход, его полностью заменили аудит-таблицы и триггеры базы данных
- ✗Когда в системе больше одного сервиса и у каждого своя база данных
- ✗Когда история изменений — бизнес-требование, как в учёте денег
- ✓В CRUD-домене и при строгой согласованности
Что спросят дальше
- Как бы вы выбрали первый контекст для event sourcing?
- Чем аудит-таблица отличается от event sourcing?
Разбор темы
- CQRS и Event Sourcing
Разделение моделей чтения и записи, цена рассинхронизации, событие как источник истины, снапшоты и версионирование событий, и честный ответ на вопрос «когда это не нужно».
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.