Produkt přišel s požadavkem na vývoj služby věrnosti, která na základě počtu doručených objednávek (hlavní systém objednávek OMS) bude poskytovat službě pro zadávání objednávek (pokladna) výši slevy. Služba věrnosti zatím nebude mít front-end, je třeba v databázi uložit mapování, od jakého počtu doručených a ne zrušených objednávek je jaká sleva. Něco jako: Objednávky Sleva [procento]% [procento]% [procento]% [procento]% Je nutné navrhnout službu, navrhnout mechanismy integrace se službou zadávání objednávek a službou správy objednávek. Je třeba navrhnout architekturu služby, kterou lze předat vývojovému týmu a týmu nasazení.

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

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

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

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

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

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

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

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

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

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

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

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