Продукт пришел с запросом разработать сервис Лояльности, который на основе количества доставленных заказов (мастер-система по заказам OMS) будет отдавать сервису оформления заказа (cashier) размер скидки. Сервис Лояльности пока не будет иметь фронтовой части, только в БД надо хранить мапинг от какого количества доставленных и не отмененных заказов какая скидка. Что-то вида Заказов Скидка [phone]% [phone]% [phone]% [phone]% Необходимо спроектировать сервис, предложить механизмы интеграции с Сервисом оформления заказа и Сервисом управления заказами. Необходимо спроектировать архитектуру сервиса, которую можно будет передать в команду разработки и развертывания.

Для сервиса Лояльности, который на основе количества доставленных и не отменённых заказов выдаёт размер скидки, предлагаю следующую архитектуру и интеграционные механизмы:

Архитектура сервиса

• Хранение данных: В базе данных хранится таблица с маппингом "минимальное количество заказов" → "размер скидки".
• API: RESTful или gRPC сервис с методами:
  • Получить скидку по количеству заказов
  • Обновить правила скидок (администрирование)

Интеграция с OMS (сервис управления заказами)

• OMS отправляет события о доставленных и не отменённых заказах (например, через очередь сообщений или webhook).
• Сервис Лояльности подписывается на эти события и обновляет внутренний счётчик заказов для каждого пользователя.

Интеграция с сервисом оформления заказа (cashier)

• При оформлении заказа cashier запрашивает у сервиса Лояльности текущий размер скидки для пользователя.
• Сервис Лояльности возвращает актуальную скидку на основе количества доставленных заказов.

Технические детали

• Использовать кеширование для ускорения ответов cashier.
• Обеспечить идемпотентность обработки событий от OMS.
• Логировать изменения скидок для аудита.

Пример структуры таблицы скидок

Минимальное количество заказов	Скидка (%)
1	5
5	10
10	15

Такой подход позволит легко масштабировать сервис и добавлять новые правила скидок без изменения клиентских сервисов.