Ապրանքը եկել է հարցով՝ զարգացնել Լոյալտի ծառայություն, որը հիմնված է առաքված պատվերների քանակի վրա ( OMS պատվերների գլխավոր համակարգը ), և որը կտրամադրի վճարման ծառայությանը (կասսա) զեղչի չափը: Լոյալտի ծառայությունը դեռ չի ունենալու առջևի մասը, միայն տվյալների բազքում պետք է պահել համապատասխանումը՝ թե քանի առաքված և չեղարկված պատվերներից ինչ զեղչ: Որոշակի տեսք ունի: Պատվերներ Զեղչ [համամասն]% [համամասն]% [համամասն]% [համամասն]% Պետք է նախագծել ծառայություն, առաջարկել ինտեգրման մեխանիզմներ՝ պատվերների ծառայության և պատվերների կառավարման ծառայության հետ: Պետք է նախագծել ծառայության ճարտարապետությունը, որը կարող է փոխանցվել զարգացման և տեղադրման թիմին։

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

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

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

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

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

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

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

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

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

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

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

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