Разбор 12. Событийная архитектура и CQRS в мультитенантных платформах¶
Статус: ревизия №2 по итогам аудита корпуса · 10.10.2026. Числовые факты сопровождаются ссылками; канонические перечисления — в «Модели данных», §0.
Академическая серия, выпуск 12. Архитектурное обоснование ядра платформы: почему остатки, отчёты и интеграции строятся на потоке событий, а чтение отделено от записи (CQRS).
1. Определения¶
| Термин | Определение |
|---|---|
| Событие | Факт, произошедший в системе, зафиксированный неизменяемой записью (кто, что, когда, над чем) |
| Событийное хранение (event sourcing) | Хранение состояния системы как упорядоченного лога событий; текущее состояние — проекция лога |
| Событийная шина | Инфраструктура доставки событий производителям → потребителям |
| CQRS | Разделение модели записи (команды, изменяющие состояние) и моделей чтения (оптимизированные проекции) |
| Идемпотентность | Повторная обработка события не меняет результат дважды |
| Согласованность в конечном счёте | Читатели видят изменения не мгновенно, но гарантированно за конечное время |
2. Почему это правильно именно для ресторанной платформы¶
- Офлайн-первый фронт: касса без облака пишет события в локальный журнал и синхронизирует их пакетом — событийная модель делает офлайн естественным режимом, а не аварийным.
- Аудитируемый склад: остаток = проекция журнала движений; любой вопрос «почему −3 кг?» разрешается журналом (см.
../components/04-inventory-procurement.md). - Интеграции без ядра-монолита: ОФД, ЕГАИС, ЧЗ, агрегаторы, вебхуки партнёров — потребители одного и того же потока событий.
- Разные скорости чтения: кассиру нужна миллисекундовая свежесть заказа, владельцу — минутная аналитика; CQRS даёт каждому свою проекцию без конкуренции за одну таблицу.
- Франшизная телеметрия: события точек — сырьё дашборда УК и роялти-биллинга.
3. Инженерные следствия (обязательные практики)¶
- Версионирование событий: схема события эволюционирует; старые события читаются старыми правилами.
- Ат-леаст-уанс доставка + идемпотентные обработчики (с точностью «ровно один раз» не гарантируется без издержек).
- Детерминированные проекции: любая витрина пересчитывается из лога с нуля (восстановление после ошибок).
- Разделение записи по агрегатам: заказ, смена, движение склада, гость — отдельные агрегаты со своими инвариантами.
- Ретеншн и компакция: горячий лог, холодный архив, политики хранения ПДн.
4. Риски и как их держим¶
| Риск | Мера |
|---|---|
| Сложность отладки распределённых потоков | Трассировка события по всей цепочке (id события сквозной) |
| Соблазн «ещё одну проекцию на коленке» | Каталог проекций в ../components/12-data-model.md, ревью новых |
| Конфликт версий при офлайн-слиянии | Правила слияния по агрегатам (последний писавший + бизнес-правила для инвариантов) |
5. Соответствие платформе¶
Платформенный слой (../components/11-integration-platform.md); контракты событий и вебхуков (../components/12-data-model.md, раздел 10).
6. Источники¶
- Фаулер М. Работы по событийному хранению и CQRS (martinfowler.com).
- Клеппман М. Высоконагруженные приложения, 2017 (главы о репликации, потоках, согласованности).
- Собственная спецификация платформы:
../components/11-integration-platform.md.