Паттерны CQRS и Event Sourcing в микросервисной архитектуре

CQRS (Command and Query Responsibility Segregation) — это паттерн, который предлагает разделить операции чтения и записи на отдельные типы операций: Query (запросы) и Command (команды).

Query — операция, которая возвращает данные из хранилища, но не изменяют его. В HTTP Query соответствует метод GET.

Command — операция, которая изменяет состояние хранилища, но не возвращают данные. В HTTP Commands соответствуют методы POST/PUT/PATCH/DELETE.

Event Sourcing — паттерн хранения данных в виде последовательности событий. Идея в том, чтобы записывать в БД каждое событие, которое меняет состояние какой-либо сущности.

База данных, куда записываются события, называется event source. Данные в ней изменять нельзя, и, как правило, они записаны в денормализованном виде – специально, чтобы операция чтения выполнялась как можно быстрее.

Как CQRS и Event Sourcing работают вместе?

Организуем два хранилища данных:
💩Первое – первоисточник данных. Используется в командах
💩Второе – оптимизированное для чтения хранилище. Данные сюда сохраняются после выполнения команд.

Процесс при выполнении команд:
1. Микросервис получает команду, проверяет её валидность
2. Если команда валидна, микросервис выполняет команду и генерирует событие
3. Микросервис сохраняет событие в хранилище-первоисточник
4. Микросервис публикует событие в очередь сообщений, где его могут подписаться другие микросервисы
5. Каждый микросервис, который подписан на это событие, обновляет свое хранилище для чтения, применяя событие к своей проекции данных.
6. В хранилище для чтения получаем новый слепок состояния первоисточника данных

При обработке запросов
1. Микросервис получает запрос, который должен вернуть данные из системы.
2. Микросервис обращается к своему хранилищу для чтения (event source), и возвращает данные, не обращаясь к хранилищу для записи.

✅ Преимущества CQRS и Event Sourcing

💩Независимое масштабирование. CQRS позволяет раздельно масштабировать нагрузки чтения и записи, снижая риски конфликтов
💩Оптимизированные схемы данных. Для query можно применить схему, оптимизированную для запросов, а для command — другую схему, оптимизированную для изменений
💩Безопасность. Разделение операций позволяет настроить более гибкую систему доступа.
💩Восстановление состояния. С помощью Event Sourcing можно восстановить состояние системы на любой момент времени, откатить ошибочные операции или исправить поврежденные данные.

⛔️ Недостатки

💩Сложность. Несмотря на простоту идеи, реализация CQRS + Event Sourcing может привести к усложнению проекта приложения, особенно если реализовывать его в связке с другими паттернами, такими как Domain-Driven Design, Saga, Eventual Consistency и т.д.
💩Несогласованность данных. Из-за асинхронной природы обмена сообщениями, данные в хранилищах для чтения и записи могут быть не согласованы на некоторое время.
💩Сложнее тестирование и отладка

📎 Статьи
1. Паттерны CQRS и Event Sourcing
2. Погружение в CQRS
3. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS: часть 1 и часть 2
4. Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS
5. Сможет ли Event Sourcing перерасти базы данных?

#архитектура

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу