Design a Coupon/Promo Code System

Problem statement

Design a coupon/promo code system that lets marketing create discount campaigns, shoppers apply codes at checkout, and finance control spend. The platform must validate codes against eligibility rules (expiration, usage limits, minimum spend, customer segment, product scope), recalculate order totals deterministically, enforce unique and multi-use constraints under concurrency, and stream usage analytics back to campaign owners.

A naive design treats this as a lookup table: code -> discount. That view collapses under three pressures. First, correctness: a discount that miscalculates by one cent on millions of orders is a material financial error, and rounding rules are a contract with the customer. Second, concurrency: a flash-sale code with a 5,000-redemption cap and 40,000 carts trying to use it in ten seconds must never oversell, and every redemption must survive retry without double-counting. Third, budget: marketing budgets are real money, and a system that allows €2M of discounts against a €1.5M budget is a failure even if every individual validation is correct.

Why the problem is distinctive

Coupons sit at the intersection of three subsystems that tolerate error differently:

• Checkout demands low latency (a shopper waits on Apply Code) and absolute price correctness — the cart total is a promise.
• Marketing demands flexibility — percentage, fixed, BOGO, free-shipping, buy-X-get-Y, stackable bundles, customer-segment targeting — and fast campaign turnaround.
• Finance demands control — budgets, caps, reconciliation, audit trails, refund semantics when an order returns.

The problem requires code creation with percentage or fixed discount, validation rules (expiration, usage limits, min spend), checkout recalculation, and marketing analytics. Scalability under thousands of simultaneous redemptions, caching for fast validation, fault tolerance so usage is never lost mid-checkout, and campaign effectiveness analytics are the non-functional pillars.

The four planes

1. Catalog plane — immutable campaigns and codes, approval workflow, targeting rules, budget envelopes.
2. Validation plane — hot-path evaluation at cart time and order confirmation, sub-50 ms cached lookups, deterministic discount math.
3. Ledger plane — usage counters, idempotent redemption events, budget consumption, refund and reversal handling.
4. Analytics plane — event streams feeding attribution, incrementality, ROI, and cohort dashboards.

A strong answer keeps these planes separate. Validation must stay fast even while the ledger is reconciling. The ledger must be correct even while analytics lags. The catalog must be immutable once approved, because a live edit to a campaign's rules silently changes the financial meaning of orders already discounted under it.

Public operating baseline versus design assumptions

Real systems exist at serious scale: Shopify's Discounts API serves millions of merchant stores; Amazon publishes tens of millions of items; Uber Eats and DoorDash run promotions across hundreds of millions of orders per quarter. Those are cited as category context. Every capacity figure used for back-of-envelope math in this answer is an explicit design assumption, labeled as such, for a fictional mid-size marketplace.

The core invariant to state in the first two minutes: a coupon is not a discount; it is a financial instrument with rules, a budget, and a ledger. Everything else follows.