19. Read Model на событиях: выбор между JOIN, REST, Replica и CQRS

В этом видео я разбираю реальный архитектурный вызов: бизнес хочет аналитику по жизненному циклу заказа – время создания, оплаты, отправки уведомления. Данные живут в трёх независимых микросервисах (Order, Payment, Notification) у двух из которых свои базы данных. Как построить аналитику, не нарушая инкапсуляцию и не создавая синхронной связанности? Я пройду через все популярные альтернативы: 🔹 SQL JOIN между базами – почему это антипаттерн 🔹REST-агрегация – почему не масштабируется 🔹Read Replica – почему не решает проблему агрегации 🔹CDC → ClickHouse – когда это оправдано, а когда избыточно 🔹CQRS + Event‑driven Read Model Projection – наш выбор и его цена Я не просто показываю «как сделать CQRS», а объясняю процесс принятия решения: оцениваю стоимость, производительность, надёжность, сложность и поддерживаемость. Что вы узнаете: 🔹Как отличить операционную аналитику от OLAP-хранилища 🔹Почему CQRS – это не «две базы данных», а принцип разделения команд и запросов 🔹Как строить идемпотентные проекции с помощью INSERT ... ON CONFLICT 🔹Как защитить read-модель от старых событий 🔹Как оценивать архитектурные альтернативы по таблице критериев Проект OrderHub доступен на GitHub: ⏱ Таймкоды: 00:00 – Вступление 02:04 – Исходная система и новая бизнес-задача - бизнес хочет аналитику 04:00 – Доработка существующего кода 25:00 – Проблема распределённых данных: почему JOIN между базами – не решение 29:27 – REST-агрегация и её проблемы 35:16 – Read Replica: что даёт и что не решает...