CQRS — один из самых популярных вопросов на собеседованиях Java/backend-разработчиков, связанных с взаимодействием микросервисов.

При этом обычно не задают вопрос в формате «Дайте определение CQRS», а формулируют его через реальный сценарий.

Сценарий:

Сервис заказов на e-commerce платформе в данный момент обрабатывает все операции (массовое создание и обновление заказов, поиск заказов клиентов, формирование сложных отчётов по продажам) через одну общую реляционную базу данных.
Во время пиковых нагрузок тяжёлые отчётные запросы вызывают серьёзные замедления транзакционных операций, что ухудшает пользовательский опыт. Кроме того, сама модель данных заказов становится чрезмерно сложной, пытаясь одновременно удовлетворить разные потребности.

Вопросы:

Определите проблему: Какую ключевую архитектурную проблему этот пример демонстрирует в части работы с данными и почему единая модель данных не справляется?

Предложите решение: Как вы бы переработали этот сервис, чтобы устранить проблемы с производительностью и избыточной сложностью? Назовите архитектурный паттерн и его основной принцип.

Ответ:

CQRS решает эту задачу за счёт разделения моделей и баз данных для записи и чтения.

Запись (заказы): команды обновляют выделенную нормализованную базу для записи (оптимизированную под транзакции).

Чтение (отчёты): события записи асинхронно обновляют отдельную денормализованную базу для чтения (оптимизированную под быстрые запросы и отчётность).

CQRS чаще всего реализуется с использованием брокера сообщений.

👉 Java Portal