⚡️ CQRS
4 буквы, смысл один:
"Принцип разделения операций чтения и записи"

Распишу предпосылки для его использования. Чтобы на собеседование вы смогли понять, что данные обстоятельства идеальны для его применения.

На интервью нужно уметь оценивать отношение операций чтения к операциям записи.
Зачастую, чтений на порядки больше.
1️⃣ Такие чтения бывают ресурсоёмкие. К примеру, нужно много join'ить, чтобы получить нужную информацию.
2️⃣ Если использовать классический подход - одна база данных для чтений и записей - то каждым таким чтением будем нагружать БД.
3️⃣ Если есть обозреватель, которому нужно получать только определенный вид данных, то не обязательно join'ить на каждый запрос чтения.
Поэтому выделяем отдельную сущность для чтения.

Это может быть материализованное представление. Когда ответ уже готов к выдаче.
Или много таких представлений. Если есть разные обозреватели, которым требуются разные виды данных на чтение.

Всё. Теперь вы знаете что такое принцип CQRS(Command Query Responsibility Segregation). И при каких обстоятельствах его применять.
Это был easy уровень. Выжимка из большого кол-ва информации в интернете.

middle уровень
🔥 Для тех, кто любит погорячее.

Такую сущность можно выделить ещё более явно. В отдельную Базу Данных. Зачем?
✅ Мы можем выбрать БД, оптимизированную под данный тип данных и под их быструю отдачу.
Также и для БД для операций записи.
✅ Положительный side-эффект от такого выделения - теперь у нас два независимых трака работы с данными!
Рушится запись? Остаётся чтение! И наоборот. Повысили отказоустойчивость системы.
Не можете сделать заказы в онлайн магазине? Печаль. Зато можете просматривать товары. Система отвалилась не полностью.

Изобрели серебряную пулю? Как бы не так.😕
Модель согласованность деградировала до "eventual consistency" - "согласованность в конечном счёте".
Теперь мы не читаем с той же БД, в которую только что записали. Где можно было бы обеспечить транзакционность.
Пишем оптимизированно в одну БД, читаем из другой. А как же свежие данные оказались доступны для чтения?

Есть различные ответы на этот вопрос.
1) Сервис между базами данных подкачивает изменения из БД для записи в БД для чтения.
2) Сервис, который пишет в БД для записи сам откидывает изменение в БД для чтения.
3) Сервис, который пишет в БД для записи кладёт записи и в брокер сообщений. Из этого брокера считывает другой сервис, который обновляет данные в БД для чтения.

❇️ Появилась дополнительная сущность, отвечающая за синхронизацию данных.
❌ Она же является и дополнительной точкой отказа.

⏱ Именно из-за этой синхронизации модель согласованности данных стала "eventual consistency".
Нужно некоторое конечное время, что перенести обновления.
В отличие от строгой согласованности, когда:
"Все пользователи всех нод в одно и тоже время видят одно и тоже значение записи."

Здесь же записавший понимает, что данные записаны. А читатель их ещё не видит.
Поэтому такой подход нельзя применять в банковских системах, где нужно гарантировать ACID.

А в онлайн магазине - пожалуйста. И в системе заказа еды. Или же - в системе по ведению работы с клиентами с многочисленными формализованными отчётами.

senior уровень
📗 Больше о терминах
Операции записи объединяются под термином "command" - команда. Чтобы более точно передать смысл - "отдаём команды на выполнение". Не ожидаем данных. Только подтверждение успешности выполнения/принятия команды.
Операции чтения объединяются под термином "query" - запрос. Это именно получение данных без их изменения.

📔 Event Sourcing
Обозначу, что есть системы, построенные на генерации, обмене, использование событий.
Бывает, что говоря о CQRS подразумевают использование этих event'ов. Но нет.
Это два разных подхода. Которые могут использоваться вместе.

—————
Завтра стартует High Load 2023.
Среди докладов есть "Эволюция и мифы CQRS" Андрея Цветцих. Хочу попасть к нему. Послушаю. Расширю восприятие темы.

#SystemDesignInterview #SystemDesign #CQRS