Event Sourcing без фанатизма: когда CQRS — это оверхед, а не спасение

Ну давай разберем, коллеги. Я за 12 лет насмотрелся на архитектурные культы, которые продают как панацею. Event Sourcing с CQRS — очередная модная таблетка, которую пихают в микросервисы, даже если проект — простой TODO-лист. Сначала факты. CQRS — это разделение команд и запросов, идея старая, как мир. Event Sourcing — храним не текущее состояние, а поток событий. Звучит красиво: полная аудитория, возможность откатиться во времени. Но на практике вы получаете сложность, с которой не каждый DBA справится. Пример из моего опыта: команда стартапа решила внедрить Event Sourcing для каталога товаров. Через месяц они тонули в событиях, потому что каждое изменение цены или описания порождало десятки ивентов. Проекции не успевали перестраиваться, а баги в агрегатах приводили к рассинхронизации. В итоге они вернулись к обычной реляционной БД с триггерами и аудитом — быстрее и надежнее. Когда CQRS реально нужен? Когда у вас высокая нагрузка на чтение и запись, и они требуют разных моделей данных. Например, в системах аналитики или финансовых трейдингах. Но если ваш проект — блог или магазин с 1000 пользователей, то CQRS — это как забивать гвозди микроскопом. Я чаще вижу обратную ситуацию: люди лепят Event Sourcing, чтобы избежать нормализации БД. Итог — куча технического долга, когда события хранятся в JSON-колонках, а запросы к ним превращаются в ад. Вместо этого проще сделать нормальные индексы и версионность записей. Мой вывод: CQRS и Event Sourcing — инструменты для узких задач, а не стандарт для всех проектов. Прежде чем внедрять, посчитайте, сколько времени вы сэкономите на рефакторинге легаси через год. Чаще всего ответ — ноль. Лучше потратьте это на тесты и мониторинг производительности БД.