Problem Statement: Coupon & Promotions Platform
Why promotions are a distributed-systems problem, not a discount field
Problem Statement: Coupon & Promotions Platform
A coupon and promotions platform is a real-time pricing-decision engine that sits on the checkout critical path. Merchandisers launch promotions — percentage-off, fixed-amount, BOGO, free shipping — and shoppers apply codes at the cart or checkout, and for every basket the system must answer three questions in milliseconds: Is this code valid for this basket? What is the discounted total? Can we still honor it once payment is captured? Get any of those wrong and you either lose money (over-discounting, double-redemption) or lose the sale (a valid code rejected at the worst moment).
The defining insight is that a promotion is not a static discount_percent column on a product. Real platforms model promotions as versioned rules carrying a budget, per-user and global caps, category inclusions and exclusions, schedule windows, and a stackability matrix that decides whether two promotions can combine. That rule object — not the discount number — is the thing the system stores, evaluates, caps, and audits, and treating it as data merchandisers edit without an engineering deploy is what makes the platform usable.
Three real products illustrate the edges. Amazon optimizes for massive concurrent redemptions when a Prime Day code goes live and millions of carts validate the same campaign at once. Groupon sells pre-purchased vouchers with hard inventory-like limits, so the budget is a real countdown that must never oversell. RetailMeNot optimizes click-to-merchant attribution, where the hard problem is leakage and fraud at the affiliate boundary. Naming which of these edges the interviewer cares about reframes the whole design.
The platform serves four actors with different stakes, and the tension between them is the heart of the problem.
| Actor | Goal |
|---|---|
| Shopper | Apply a code and see the price update instantly |
| Merchandiser | Launch campaigns without an engineering deploy |
| Finance | Audit liability and margin impact to the cent |
| Fraud team | Block coupon farming and collusion rings |
Marketing wants velocity and generous stacking; finance wants the budget enforced exactly; the shopper wants instant feedback; fraud wants to throttle abuse. State early that the system is strongly consistent on money (budget and redemption counts) and eventually consistent on analytics — that one sentence frames every later trade-off.
Key Highlights
- •A promotion is a versioned rule (budget, caps, exclusions, schedule, stackability matrix) — not a static discount_percent column
- •The validate path must answer three questions in milliseconds: valid for this basket? what's the total? can we still honor it after capture?
- •Strongly consistent on money (budget + redemption counts), eventually consistent on analytics — the framing that drives every trade-off
- •Real edges differ: Amazon = concurrent-redemption scale, Groupon = hard voucher inventory, RetailMeNot = affiliate attribution/leakage
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Coupon & Promotions Platform, I'll separate validate (read) from finalize (write) so we never double-decrement on retries."
- "If asked about Groupon, I'll pivot to prepaid voucher ledger—not just percent-off rules."