Design a coupon and offers engine

Avoid hard-coding offers in if-else code; marketing creates new ones daily. Model an offer as conditions plus benefit. Conditions are a small tree of typed predicates: user (is_new, segment in [...], order_count < 3), cart (subtotal >= 49900 paise, contains category 'pizza', brand = X), context (city in [...], time between 22:00-02:00, platform = android), payment (method = card, bin range in HDFC list). Benefits: flat, percent with max cap, free delivery, BOGO on the cheapest item, cashback credited later. Keep the predicate language limited and typed rather than letting marketing write arbitrary scripts; it is safer, can be validated at creation and can be compiled. Evaluation speed comes from indexing: build inverted maps from dimensions (city, category, payment method, code) to offers so each request evaluates only tens of rules. Evaluators are stateless and hold the compiled index in memory; on an OfferChanged event they rebuild and swap atomically. Store the offer version in each redemption so later disputes see the exact rule that was applied.

'First 10,000 orders' or 'Rs 50 lakh budget' are shared counters hit by many checkouts at once. Read-check-write in the application races and overshoots. Use an atomic check-and-increment: a Redis Lua script that checks per-user count, global count and budget, then increments all, or nothing. Redis gives ~100k ops/s per shard; put all keys for one offer in one hash slot using a hash tag ({offer:123}) so the script can touch them, and keep per-user keys separate or in the same slot with the offer tag. Reserve at order creation, confirm on payment, release on failure, like inventory. Because Redis can lose recent writes on failover, the redemptions table is the durable truth: on recovery, rebuild counters as the sum of RESERVED + CONFIRMED rows. For very hot offers, you can pre-allocate budget chunks to evaluator pods (e.g. 1,000 uses at a time) to reduce contention, accepting a small overshoot or undershoot at the end. Tell the interviewer what tolerance the business accepts: overspending 0.1% of a budget is usually fine, double-using a single-use code is not.

Users expect the app to pick the best deal. With stacking groups (one coupon, one bank offer, one free-delivery offer), the search space is small: for each group pick at most one offer, so brute force over a few candidates per group is fine. Order matters: a percent offer applied after a flat one gives a different total, so define a fixed order (item-level offers, then cart-level coupons, then payment offers on the remaining amount) and stick to it. Always use integer paise and round in one direction at a defined step to avoid one-paisa mismatches between cart, invoice and refund. Apportion each discount across eligible lines in proportion to their value, with the remainder on the largest line; this matters for GST invoices (tax is on the discounted value), partial cancellations (refund the line's net price) and billing brands for brand-funded offers. Cashback offers are not a price reduction; they create a wallet credit after delivery, so they belong in a separate post-order flow.

Coupons are money, so they attract fraud. Common patterns: one person creating many accounts for 'new user' offers (detect with device ID, phone, payment instrument and address fingerprints; tie 'new user' to device and instrument, not just account); public leaks of codes meant for a partner (use unique single-use codes or bind codes to user IDs); bots brute-forcing short codes (rate limit code attempts per user and IP, use long random codes); order-and-cancel loops to farm cashback (release only after delivery, cap per device); and internal mistakes such as a missing max cap on a 50% offer during a sale. Guardrails: mandatory max cap and budget for percent offers, a second approver for offers above a value threshold, budget burn-rate alerts (spending 30% of a day's budget in 10 minutes means something is wrong), and a kill switch that pauses an offer within seconds through the event pipeline.

A typed predicate tree is fast, safe and easy to validate and explain. A general rules engine is flexible but heavier and harder to reason about. Arbitrary scripts are dangerous. Start with a typed tree and add predicate types as needed.

Reserving at order creation guarantees the user gets the discount they saw when paying, at the cost of holding uses for unpaid orders (released after a timeout). Reserving after payment risks charging the full price or honouring an exhausted offer.

DB counters with conditional updates are durable but hot rows limit throughput. Redis is fast but needs rebuild-from-ledger on failover. Use Redis for hot campaigns, with the redemptions table as truth.

Auto-applying improves conversion and fairness; letting users choose matters when offers differ in type (cashback vs instant). Auto-apply the best instant discount and show others.

Thousands of redemptions per second on one offer's counters. Hash-tag keys to one slot and keep the Lua script tiny; if needed, pre-allocate chunks to pods; move evaluation-time limit checks to cached values to avoid read load on the same keys.

Showing offer badges on every listing card multiplies calls. Precompute non-personal badges ('20% off') into the catalogue/search index and only evaluate personal offers in the cart.

Evaluation still works with rules only (limits treated as available). Redemption checks fall back to conditional updates on the database for limited offers, at lower throughput, or pause limited offers while unlimited ones keep working.

Reserved redemptions without confirm or release are swept after 30 minutes by checking the order state with the order service, so uses are not leaked forever.

Burn-rate alerts fire within minutes; the kill switch pauses the offer through an event to all evaluators. Orders already placed are honoured or handled per policy; the audit log shows who approved it.