Handling coupon refunds and partial refunds when coupon budgets are enforced via Redis counters

Its hard to work out your exact business logic here. I'm going to assume

1. You print and distribute lots of identical coupons. ie 10% product X
2. Customers are limited to n of the same type of coupon
3. types of coupons are limited to m total usages. ie although you printed 100,000 coupons, you will only redeem say 100.

You already have a working solution for these counters, but it doesn't take into account refunds.

In which case the simplest option would be to double up and have refund counters for the same key. Then instead of checking used < limit, you just check used - refunds < limit

In practice, my experience is that with refunds, companies are much more worried about fraud than whether the marketing budget is a few percent under or over.

I would expect them to use atomic transactions to ensure coupons cannot be reused, or exceed whatever limit's have been set on a per customer basis

But not be overly worried about going over or under the total usage. So an end of day, or once per X transactions check on the total coupons used would be fine.

Your redis solution seems good, but might be overkill given memory prices.

Additional Clarification.

I have seen a similar problem at a large retailer. Stock Levels. In this case the retailer has an ecommerce website. The requirement is to put "Low Stock" warnings/adverts against products that have less than X items left in stock. When there are zero items left the product should no longer be displayed.

Because the stock levels change with each purchase and need to be queried for every view of the webpage this would require the website to be regenerated from the database on every view. Rather than be cached or loaded from a CDN. Which would break the website under load.

Updating the products stock level with a purchase is not an issue. A purchase requires server side and database activity anyway and purchases and much less frequent than page views, so the purchase pages are not cached.

The solution for the product view page is to check the stock levels on cache refresh only.

This means that some products which should not be shown, or should be shown with the "low stock" tag are incorrectly shown, or shown without the tag.

Also it means some purchases will attempt to buy products which have no stock. These purchases will fail "sorry we have run out of that item"

However, it requires no further infrastructure ie. its cheap. and it scales.

Sometimes product which the website thinks are out of stock, will have had returns or cancelled orders. So sometimes sales are gained from the incorrect display.

When a sale is unable to complete, the customer can be offered an alternative, whereas if they couldn't find the product at all,the whole basket may have been lost as they would go elsewhere.

This solution keeps the static cache requirement for the view page, so it scales much more cheaply than your redis cache, with negligible downsides