Реактивная архитектура - это архитектура построенная на сообщениях. Один из вариантов сообщений - события, которые могут быть выполнены с разной степенью детализации. В реактивных архитектурах распространенным способом обмена сообщениями является - очередь или шина сообщений. Разделение на типы сообщений условно.

В рамках данного стрима рассмотрим архитектуру реактивного приложения, использующего следующие паттерны:

- CQRS
- SAGA
- EventSourcing

Идея архитектуры заключается в построении модульного монолита, грануляция происходит за счет разделения на слабосвязанные модули, которые обмениваются между собой локальными событиями, масштабирование системы может быть выполнено за счет выделения доменных событий, содержащих всю необходимую информацию и распространяемых через EventStore.

Плюсы:

- быстрый старт;
- возможность малой командой разрабатывать монолитное приложение, 
которое легко рефакторится к сервисной и даже микросервисной архитектуре;
- гибкая архитектура.

Минусы:

- требует подготовки;
- чувствительна к неправильной грануляции.

Основная идея: разделение потока команд и запросов. Паттерн может быть реализован в синхронном и асинхронном режиме. При этом нет жесткого требования физического разделения БД, в конечном счете это зависит от нагрузок.

Основная идея: организовать последовательное выполнения цепочки действий, с учетом локального стейта каждого сервиса. В роли сообщения может выступать событие, которое внутри сервиса может быт разбито на команды.

Существует два основных способа управления потоком:

- Хореография - когда сервисы сами решают как реагировать на поступающие сообщения
- Оркестрация - когда существует промежуточная сущность отвечающая за формирование 
конечное выполнение действий

Основная идея: хранить не результирующий стейт, а цепочку событий с изменениями, где каждое событие содержит необходимые данные для восстановления стейта. При этом существуют локальные реплики данных, которые используются в сервисах для оперативной работы.