The product came with a request to develop a Loyalty service, which based on the number of delivered orders (master system for orders OMS) will provide the discount size to the order processing service (cashier). The Loyalty service will not have a front-end part for now, only a mapping in the database to store which discount corresponds to which number of delivered and not canceled orders. Something like: Number of Orders Discount [phone]% [phone]% [phone]% [phone]% It is necessary to design the service, propose integration mechanisms with the Order Processing Service and the Order Management Service. It is necessary to design the architecture of the service, which can be handed over to the development and deployment team.

For the Loyalty service, which issues a discount based on the number of delivered and non-canceled orders, I propose the following architecture and integration mechanisms:

Service Architecture

• Data Storage: A database table maps "minimum number of orders" to "discount size".
• API: A RESTful or gRPC service with methods:
  • Get discount by number of orders
  • Update discount rules (administration)

Integration with OMS (Order Management Service)

• OMS sends events about delivered and non-canceled orders (e.g., via message queue or webhook).
• The Loyalty service subscribes to these events and updates the internal order count for each user.

Integration with the order placement service (cashier)

• When placing an order, the cashier requests the current discount size for the user from the Loyalty service.
• The Loyalty service returns the current discount based on the number of delivered orders.

Technical details

• Use caching to speed up responses from the cashier.
• Ensure idempotency in event processing from OMS.
• Log discount changes for audit purposes.

Example of discount table structure

Minimum number of orders	Discount (%)
1	5
5	10
10	15

This approach will allow easy scaling of the service and adding new discount rules without changing client services.