პროდუქტი მივიდა მოთხოვნით, რომ განავითაროს ლოიალობის სერვისი, რომელიც დაფუძნებულია მიწოდებული შეკვეთების რაოდენობაზე (OMS შეკვეთების მთავარი სისტემა) და რომელიც გადაეცემა გადახდის სერვისს (კასსერი) ფასდაკლების ზომას. ლოიალობის სერვისი ჯერ არ ექნება ფრონტ-ენდი, მხოლოდ მონაცემთა ბაზაში უნდა იყოს შენახული მეპარება, თუ რამდენი მიწოდებული და არ გაუქმებული შეკვეთა ემთხვევა რა ფასდაკლებას. რაღაც მსგავსი: შეკვეთები ფასდაკლება [პროცენტი]% [პროცენტი]% [პროცენტი]% [პროცენტი]% საჭიროა სერვისის დიზაინი, ინტეგრაციის მექანიზმების შეთავაზება შეკვეთების სერვისთან და შეკვეთების მართვის სერვისთან. სერვისის არქიტექტურის დიზაინი, რომელიც შეიძლება გადაეცეს განვითარების და განთავსების გუნდს.

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

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

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

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

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

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

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

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

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

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

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

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