Toode tuli taotlemisega ar lojaliteedi teenuse väljatöötamiseks, mis põhineb kohaletoimetatud tellimuste arvul (OMS tellimuste peasisüsteem) ja mis edastab makseteenusele (kassasse) allahindluse suuruse. Lojaliteedi teenusel ei ole praegu front-endi, vaid andmebaasis tuleb hoida kaardistust, millise koguse kohaletoimetatud ja mitte tühistatud tellimuste puhul kehtib milline allahindlus. Midagi sellist: Tellimused Allahindlus [protsent]% [protsent]% [protsent]% [protsent]% Vajalik on kavandada teenus, pakkuda integratsioonimehhanisme tellimuste teenuse ja tellimuste haldamise teenusega. Vajalik on kavandada teenuse arhitektuur, mille saab üle anda arendus- ja juurutusmeeskonnale.

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

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

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

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

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

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

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

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

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

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

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

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