🕺Хореография микросервисов - детальный разбор с примером 💃

👉 Хореография — это архитектурный шаблон взаимодействия микросервисов, в котором бизнес-процессы реализуются как цепочка независимых реакций на события.


Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.


👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.


👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды


🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:

1. Приложение отправляет запрос на API Gateway

2. API Gateway проверяет авторизацию и маршрутизирует заказ в Сервис Заказов

3. Сервис Заказов:
+ обновляет статус заказа в БД на "Ожидает оплаты"
+ публикует событие в Брокер Kafka - "Заказ подтверждён"
❗️ Деньги с пользователя не списаны

4. Сервис Заказов возвращает ответ на API Gateway.

5. API Gateway возвращает ответ с инфо о заказе на web-приложение, где показываем пользователю сообщение "Заказ принят"❌


🟡 Асинхронная работа - хореография:
Запускается параллельный поток событий. Frontend и пользователь могут идти по своим делам.

1. Сервис Платежи (далее - С) читает событие "Ожидает оплаты" из Kafka и запускает логику списания денег с карты пользователя.

2. Платежи публикует событие "Платеж упешен" в Kafka.


Параллельно:
----
3А. С Уведомлений читает событие "Платеж упешен" из Kafka и отправляет push+sms пользователю❌

3C. С Заказов читает событие "Платеж упешен" из Kafka и меняет его статус в своей БД на "Оплачен"❌

3B. Рестораны читает событие "Платеж упешен" и проверяет:
+ кухня не перегружена?
+ доступность блюд?
+ время работы и т.п.

4. Если ок, то С Рестораны публикует событие "Заказ подтверждён".
----

Параллельно:
4А. С Уведомлений читает "Заказ подтверждён"..❌
4C. С Заказы читает "Заказ подтверждён"..❌
4B. С Курьеры читает "Заказ подтверждён"..


Далее на картинке к посту 🖼

❌ - конец процесса

#АрхитектураGA #FoodDeliveryGA