⭐️ Интеграция с брокером Kafka в Микросервисной архитектуре: зачем СА понимать архитектуру проекта ⭐️

Чтобы сделать четкую и структурированную постановку задачи на интеграцию - технический Use Case (UC), сначала надо изучить архитектуру проекта.

👉 Это помогает:
1. Явно определять участников UC на каждом шаге
2. Понимать где, когда и какой API вызывать
3. Наглядно видеть потоки данных

Из огромной схемы архитектуры проекта #BookingGA, сделанной в рамках этой публикации, я выделила часть, которая связана с задачей:

Подключить Unisender, чтобы пользователи подписывались и получали рассылку по новым и выгодным объектам недвижимости в выбранном городе.

Далее обзорно рассказываю, как будут "ходить" запросы и данные по архитектуре для реализации задачи.

UC 1: Подписка на рассылку

1. Пользователь с Frontend подписывается на рассылку.

2. Frontend отправляет REST API запрос на подписку в Backend (API Gateway).

3. API Gateway перенаправляет запрос на сервис авторизации для проверки валидности токена.
Если успешно, то API Gateway проксирует запрос на сервис Управления Пользователями (УП), чтобы включить настройку.

4. Сервис УП сохраняет изменения настроек в своей БД и отправляет сообщение (JSON) в Kafka о новом подписчике.

Асинхронно, в фоновом режиме, Сервис Уведомлений:
4.1. Читает сообщение о подписке из Kafka.
4.2. Уточняет лист рассылок по БД, в который внести пользователя.
4.3. Отправляет запрос на подписку пользователя в Unisender.
4.4. Сохраняет в БД результат и делает отметку в Kafka об успешной обработке.


5. Сервис УП возвращает ответ об успешном включении подписки на API Gateway.

6. API Gateway возвращает ответ на Frontend, который отражает результат пользователю.

UC 2: Авторассылка новостей подписчикам

Начинается со срабатывания крона (задачи по расписанию), а далее расскажу в детальной постановке задачи 😉


Дополнительно:
🔗 Use Case для уведомлений о бронировании


Только после понимания как "ходят" данные в архитектуре, мы можем переходить к постановке задач на интеграции 🙌

#ИнтеграцииGA