The system needs to implement a flexible pricing policy. The base price for a meal will be held in Meal Types. In addition to that, final meal price could be modified by various pricing policies, according to time, place, customer type etc. The price must be recalculated every time when the policies or base price change, or when certain policies start or end. The customers should be able to see the final price at purchase or via the application. The system must be highly available and elastic to support the all purchases at peak times.
- Customers see the price of the meal in the applicaion, with high availability and reliability. When session starts get latest prices per current meals (meal types) in the fridge and “freeze” prices per session. If prices updated during the ongoing session then customer is not impacted.
- Customers see the price of the meal at the fridge during purchase, when they open the door, with high availability and reliability.
- Admins CRUD the pricing policies, which should recalculate the price.
- Admins change base meal prices, which should recalculate the price.
- Pricing Policy Service API. This service is for managing pricing policy rules per locations, time, meal types, customer credits, customer types and other attributes.
- Pricing calculation engine. Reactive engine. Consumes events of policy or base meal price change, or when certain policies start or end, recalculates the price and stores it in calculated prices DB for high availability.
- Pricing Service API for getting the latest prices via app or by fridge purchase session.High availability, high fault-tolerance.
- Pricing policy rules DB, stores policies.
- Calculated prices DB, stores calculated prices for high availability access.
- Fault Tolerance.
- Availability.
- Elasticity.
- Event-driven.
- Microservices - separate microservices API for price calculation and price access API.
- See Separate microservices for prices acces and calculation ADR for relevant architectural decision.