Давайте для начала кратко напомню, что это вообще такое.
CQRS (Command Query Responsibility Segregation)
Что это: Паттерн, который говорит: «Хватит читать и писать данные через одну и ту же модель». Мы жестко разделяем систему на две части: Команды (изменяют состояние, ничего не возвращают) и Запросы (читают данные, ничего не меняют). Физически это часто означает разные базы данных для записи (нормализованная реляционка) и для чтения (какой-нибудь денормализованный ElasticSearch или Mongo).
Плюсы:
👉Асимметричное масштабирование. У вас 10 000 чтений на 1 запись? Отлично, масштабируем только базу для чтения.
👉Оптимизация. Данные для чтения можно заранее собрать в нужном виде (DTO), чтобы отдавать их клиенту без зубодробительных
JOIN на 15 таблиц.👉Изоляция. Тяжелый аналитический запрос не положит транзакционную базу.
Минусы:
👉 Eventual Consistency. Данные из базы записи попадают в базу чтения с задержкой. Если ваш фронтенд не готов к тому, что юзер обновил профиль, а на экране всё ещё старая фотка - готовьтесь к боли.
👉 Сложность инфраструктуры. Вместо одного PostgreSQL вам теперь нужно поддерживать две БД и шину сообщений (Kafka/RabbitMQ) между ними.
Event Sourcing
Что это: Мы перестаем хранить текущее состояние объекта. Вместо UPDATE user SET status = 'active' мы сохраняем историю событий: UserCreated -> EmailVerified -> StatusChangedToActive. Текущее состояние получается путем последовательного наката всех событий (свертка). Это как бухгалтерская книга: баланс — это сумма всех проводок, а не просто цифра в ячейке.
Плюсы:
👉Идеальный аудит. Вы на 100% знаете, не только какое сейчас состояние у системы, но и как она к нему пришла.
👉Машина времени. Можно откатить систему на любой момент в прошлом или воспроизвести баг на локалке, просто прогнав события заново.
Минусы:
👉Ад с версионированием событий. Что делать, если структура события OrderPlaced изменилась через год? Старые события никуда не делись, их всё равно надо уметь читать.
👉Сложность запросов. Нельзя просто сделать SELECT * WHERE balance > 1000. Вы не знаете текущий баланс, пока не прочтете все события. (Именно поэтому Event Sourcing почти всегда используют в жесткой связке с CQRS).
Где эти подходы реально нужны сегодня?
Джуны обожают притащить все что им интересно в очередной CRUD для блога или интернет-магазина, чтобы «сделать всё по красоте». А потом через полгода команда воет от того, что добавление одного поля в табличку занимает неделю.
В современном мире эти подходы решают задачи там, где без них вы просто не пройдете аудит или ляжете под нагрузкой. Вот реальные кейсы:
Финтех и Биржи.
Ни один нормальный банк не меняет баланс через UPDATE. Деньги — это всегда события (MoneyDeposited, MoneyWithdrawn). Если налоговая или служба безопасности придет с вопросом: «Откуда у этого парня миллион на счету?», вы обязаны предоставить всю цепочку событий. Event Sourcing здесь - это не архитектурный изыск, это требование регулятора.
Системы бронирования с дикой асимметрией (Авиабилеты, Отели).
Миллионы людей ежесекундно ищут билеты на Aviasales (Запросы). И лишь единицы в эту же секунду их покупают (Команды). CQRS здесь спасает жизни: поисковый трафик бьет по супер-быстрым кэшам для чтения, а редкие транзакции покупок аккуратно складываются в надежную мастер-базу.
CQRS и Event Sourcing - спасают от конкретных тяжелых проблем (асимметрия нагрузки, строгий аудит), но если применять их бездумно (в обычном CRUD), вы просто сожжете бюджет и убьете команду.
А как у вас в компаниях? Внедряете CQRS по нужде бизнеса или потому что на Хабре написали, что так модно?
#этобаза
🤡Токсичный (it) архитектор🤡