🧐 Нужен ли здесь брокер? Разбор реальной задачи ⁉️

Начинаем проектировать архитектуру #PostamatGA.

На первом черновике схемы уже есть основные компоненты.

Ваша задача — определить, где нужен брокер.
Не просто поставить Kafka между всеми сервисами, а понять, какую проблему она должна решить 😃


📌 Основной сценарий

Пользователь оформил заказ в маркетплейсе и выбрал доставку через постамат.

Маркетплейс передал в нашу платформу данные об отправлении. Далее курьер приезжает к постамату, чтобы загрузить его.

1️⃣ Курьер сканирует QR-код посылки

2️⃣ Система резервирует свободную ячейку подходящего размера

3️⃣ Постамату отправляется команда открыть ячейку

4️⃣ Курьер загружает посылку. После чего постамат сообщает серверу, что посылка внутри

5️⃣ Отправление получает статус «Готово к получению», пользователю отправляется одноразовый код + QR

6️⃣ Пользователь вводит код.
Система проверяет его, после чего отправляет команду открыть ячейку

7️⃣ Когда дверца закрыта и посылки внутри больше нет, отправление получает статус «Выдано».

Если посылку не забрали за 72 часа, запускается процесс возврата.



⚠️ Что может пойти не так?

▫️ постамат временно потерял связь
▫️ одно событие от устройства пришло несколько раз
▫️ команда открытия ячейки была доставлена повторно
▫️ сервис уведомлений недоступен
▫️ получение и запуск возврата произошли почти одновременно


При этом:

✔️ одну ячейку нельзя назначить двум отправлениям одновременно
✔️ недоступность уведомлений не должна блокировать загрузку посылки
✔️ повторная команда не должна неконтролируемо открыть ячейку
✔️ от ввода корректного кода до открытия ячейки должно пройти не более 5-ти секунд



❓ Определите:
1. Куда вы добавили бы брокер первым?
2. Какие события через него передавали бы?
3. Какие проблемы это решит?

Попробуйте решить, а затем сверяйтесь с разбором ниже 👇

.
.
.
.
.
.
.
.
.

✅ Разбор решения

Единственного правильного варианта здесь нет. Но брокер должен появляться там, где нам нужны независимость компонентов, гарантированная доставка и повторная обработка.


1️⃣ Отправка уведомлений

Когда отправление получает статус «Готово к получению», сервис отправлений публикует событие:
ShipmentReady

Сервис управления доступом получает его, создаёт одноразовый код и QR-код, после чего формирует событие:
PickupAccessCreated

Сервис уведомлений получает его через брокер и отправляет данные пользователю.

Если сервис уведомлений или внешний SMS/Push-провайдер временно недоступен, загрузка посылки не блокируется. Сообщение остаётся в очереди и будет обработано позже.


2️⃣ События от постамата

Постамат передаёт на Backend технические события:

▫️ CellOpened — ячейка открыта
▫️ CellClosed — дверца закрыта
▫️ ParcelDetected — посылка находится внутри
▫️ ParcelRemoved — посылка извлечена

❗️Закрытая дверца сама по себе не означает, что посылка была загружена или получена. Поэтому состояние двери и наличие посылки — это разные события, которые надо контроллировать бэком.

Далее, например, событие "посылка извлечена" могут одновременно использовать:

→ сервис отправлений — чтобы изменить статус
→ сервис постаматов — чтобы освободить ячейку
→ сервис аналитики — чтобы сохранить статистику
→ сервис уведомлений — чтобы оповестить пользователя о состоянии посылки


3️⃣ Запуск возврата

Планировщик задач контролирует срок хранения отправления.

Когда 72 часа истекли, он публикует событие:
ReturnRequired

Сервис возвратов получает его через брокер и запускает процесс возврата, вкключающий смену статуса, уведомление пользователя, оповещение маркетплейста.

При этом брокер не должен использоваться как таймер на 72 часа. Срок контролирует планировщик, а брокер доставляет уже созданное событие.

Если вдруг покупатель всё же придёт за отправлением раньше забора посылки курьером, то процесс возврата должен быть прерван - это отдельное событие к обработке для брокера.



Что брокер не решает?

❌ Дубли событий
❌ Повторное открытие
❌ Потерю связи с устройством
❌ Одновременное получение и возврат
❌ Назначение одной ячейки двум отправлениям


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