Retail Pricing and Discount Data Checkout Cache

  • Article

For the performance of a business application, we can roughly split it into two areas: algorithm and persistence, especially for pricing and discount. We have focused extensively on retail discount problem and algorithm. Today, we talk about a way to enhance data access performance: pricing and discount data cache.

First, any time we have cache, we have data inconsistency. For a good caching mechanism, we need to minimize the inconsistency as much as possible. Secondly, we need to make sure it is functionally consistent. For example, during the checkout item scan, it is okay to see stale price and discount, but it is not okay to see fresh and stale prices randomly. In addition, pricing and discount data is time-sensitive. A discount is active now, but may not be active a second later, and vice versa.

Introduce pricing and discount data checkout cache.

  1. When we scan the first item, load pricing and discount data that is active anytime during a small window, say now to 10 minutes later. In other words, we have a cache-start-time and cache-end-time.
  2. The discount engine will re-check the time to filter out inactive ones at the given time.
  3. When we scan items one by one,
    • If it’s still in the cache time range,
      • If we have the item already in the checkout cart, no need to read from database.
      • If it is a new item, then load the pricing and discount data for that item only for the existing cache time range.
    • If it is outside the cache time range, drop the existing cache and start a new one, with a new cache time range.
  4. When we have new information that would change the pricing and discount data - for example, the customer scans his/her loyalty card – drop the existing cache and start a new one, with a new cache time range.
  5. Where to store pricing and discount data checkout cache?
    • If pricing engine is embedded in the POS, then in memory.
    • If pricing engine is part of a store server, then it may be persisted along the cart.

Details are important in cache effectiveness.

  • If pricing engine is part of a store server deployed in two-plus machines, a light-weighted POS may hit multiple instances of the store server during the checkout. There is no guarantee that two machines have the same time. We could make cache start time a bit earlier, say one minute before now. If two machines have huge time difference, then cache would not be effective at all. Then again, we face a much bigger problem.
  • Data inconsistency, for example, when we scan the first item, mix and match isn’t there; when we scan the second item, mix and match is available. We end up with partial mix and match data.
  • Cache cost is mostly in serialization and de-serialization. If we do not store cache in memory, or along with the cart, then we would incur additional cost.
  • Total isolation of 2 checkouts: My cache is for my checkout and yours is for yours.

Note: in Dynamics Retail Solution, pricing and discount data checkout cache is available in AX6, but not in AX7.

Related: Retail Discount Concurrency – Best Deal Knapsack Problem

Related: Dynamic Programming for Retail Discount Knapsack Problem

Related: Discount Best Deal Algorithm Performance