Лекция 217: Когда и зачем использовать CQRS

На прошлой лекции мы познакомились с базовыми принципами CQRS. А теперь давайте копнем глубже и разберемся, как этот паттерн уживается с другими архитектурными решениями, и где его действительно стоит применять.

Как CQRS и Saga уживаются вместе

Помните нашу любимую Saga с прошлых лекций? Так вот, CQRS и Saga — это как пицца и ананасы. Ну иои солёная карамель. Кто-то скажет, что это странное сочетание, но те, кто пробовал знают, что это может быть вкусно!

Давайте разберем конкретный пример. Представьте, что вы разрабатываете систему для авиакомпании:

• Saga отвечает за весь процесс бронирования: от выбора места до оплаты
• CQRS помогает не положить систему, когда тысячи пользователей одновременно ищут билеты

Как это работает вместе?

1. Команды (запись данных) идут через Saga, обеспечивая согласованность всех операций
2. Запросы (чтение) обрабатываются отдельно через CQRS, не мешая процессу бронирования

Где CQRS реально выстрелил

А теперь давайте посмотрим на реальные кейсы. И нет, я не буду снова рассказывать про Amazon и Netflix — давайте возьмем примеры поближе к земле.

Представим, что ваш знакомый работал в компании, которая делала систему онлайн-бронирования для сети ресторанов. Сначала все было прекрасно — простой CRUD-сервис на Spring Data JPA справлялся на ура. Но потом случился "Черный День" — ресторан запустил акцию "Все суши почти даром". Система легла через 15 минут — слишком много людей пыталось одновременно бронировать столики.

Как с этим справиться? Можно внедрить CQRS:

• Для записи (бронирования) — Spring Data JPA с PostgreSQL
• Для чтения (поиск свободных столиков) — Spring Cache с Caffeine или Hazelcast in-memory data grid
• В качестве брокера событий для синхронизации — Spring Cloud Stream с Kafka

Результат? Система не только выдержала следующую акцию, но и стала намного удобнее для разработки: каждая часть делает ровно то, что должна.

Где CQRS может выстрелить вам в ногу

А теперь давайте поговорим о грустном. Я видел проекты, где CQRS превращался в монстра Франкенштейна. Вот типичные ошибки:

1. "Давайте разделим вообще всё!" Разработчики так вдохновились идеей разделения, что создали отдельные модели для каждой операции. В итоге простой CRUD превратился в космический корабль с варп-двигателем.
2. "Зачем нам консистентность?" Некоторые забывают, что между записью данных и их появлением в read-модели всегда есть задержка. И если ваши пользователи видят разные данные на разных экранах - это не очень хорошо.
3. "CQRS решит все наши проблемы!" Спойлер: нет, не решит. CQRS — это как острый соус: классно работает в правильном блюде, но не стоит добавлять его в утренний кофе.

Альтернативы CQRS

Иногда CQRS — это как стрелять из пушки по воробьям. Давайте посмотрим на альтернативы:

1. Кэширование Часто простое кэширование решает 80% проблем с производительностью чтения. И его гораздо проще поддерживать.
2. Материализованные представления В PostgreSQL можно создать материализованные view для сложных отчетов. Иногда этого достаточно.
3. Вертикальное масштабирование Да, это не очень модно. Но иногда проще купить сервер помощнее, чем усложнять архитектуру.

Когда действительно стоит использовать CQRS

1. У вас реально разные требования к чтению и записи Например, запись должна быть строго консистентной, а чтение максимально быстрым.
2. Нагрузка на чтение и запись сильно различается Классический пример: социальная сеть, где на одну публикацию приходится тысячи просмотров.
3. Вы уже используете Event Sourcing CQRS отлично дополняет Event Sourcing. Но об этом мы поговорим на следующей лекции...

Заключение

CQRS — это мощный инструмент, но с ним нужно быть аккуратным. Как говорит тимлид (какой такой тимлид? Да почти любой!): "Не усложняй там, где можно упростить. И не упрощай там, где нужно усложнить".

В следующий раз мы перейдем к практике и напишем настоящий CQRS-сервис. Готовьте свои IDE!