Архитектура (паттерны

Архитектура (паттерны)

🕸 CQRS: когда разделение на чтение и запись — не усложнение, а спасение

CRUD — это просто. Один и тот же объект, одна модель, одна БД. Всё хорошо, пока проект не вырастает.

Проблемы классического CRUD на масштабе:

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

Бизнес-логика сложна: одна операция записи затрагивает 10 таблиц, а для чтения нужны данные из 5 разных агрегатов.

Сложные запросы: для отчётов и аналитики нужны JOIN-ы, которые замедляют основной OLTP.

🌌 CQRS (Command Query Responsibility Segregation):

Разделяем модель для записи и модель для чтения.

Command side: только операции изменения состояния. Без сложных запросов.

Query side: только чтение. Оптимизировано под конкретные view.

🔄 Простейшая реализация:

Команды пишут в основную БД (3NF, нормализованную).

Асинхронно (через Event Bus) данные проецируются в read-only кэш/БД.

Запросы идут в read-модель.

⏱️ Trade-offs:

Плюсы:

Масштабирование чтения и записи независимо.

Query-модель может быть денатурализованной, готовой под конкретный UI.

Разные технологии: для записи — PostgreSQL, для чтения — Elasticsearch или Redis.

Команды могут быть сложными, запросы — всегда быстрыми.

Минусы:

Eventual consistency. Пользователь что-то написал, но может не сразу увидеть результат.

Сложность системы растёт (нужен event bus, обработчики проекций).

Не для каждого CRUD-приложения.

🔮 Когда брать CQRS:

Вы строите систему с доменной сложностью (например, биллинг, бронирование).

У вас высоконагруженный read-side (миллионы просмотров, разная аналитика).

Вам нужно логировать каждое изменение (audit log).

💎 Инсайт: CQRS — это не серебряная пуля. Это инструмент для систем, где сложность бизнес-логики и/или нагрузки делает CRUD нежизнеспособным. Если у вас обычный ToDo-лист — не надо. Если вы пишете трейдинговую платформу — CQRS ваш друг.