Лекція 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 перетворювався на монстра Франкенштейна. Ось типовi помилки:

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!