system-design

Practice Problem: Design a Coupon / Discount Service

Prompt: Design a coupon service for an e-commerce platform: create coupons (percentage/fixed, with usage limits and expiry), validate and redeem them at checkout, and prevent abuse (a “one per user” or “first 1000 uses” coupon must be honored exactly). Attempt cold for 45 minutes first.

Tests: redemption limits under concurrency (the oversell problem again), validation on a hot path, abuse prevention. Reuses ticketing / e-commerce reservation patterns.

Solution outline

1. Requirements

Functional: create coupons (type, value, total-use limit, per-user limit, expiry, eligibility rules); validate at checkout; redeem (atomically consume a use); report usage.
Non-functional: 🚨 honor limits exactly — a “first 1000” coupon must not be redeemed 1001 times even under a flash-sale stampede; “one per user” must hold. Low-latency validation (checkout hot path). High read volume (many validations), fewer redemptions.
Out of scope: the pricing/cart engine, payment.

2. Estimation

Millions of validations/day (every checkout checks a coupon), far fewer redemptions. A viral coupon → a spike of concurrent redemptions on one coupon → contention (a hot key).

3. Core design — validate cheaply, redeem atomically

Split the two operations:

Validate (read-mostly): is the coupon valid, unexpired, eligible for this user/cart? Cacheable coupon metadata; fast. Slight staleness OK — the redeem step is the real gate.
Redeem (the correctness-critical write): 🚨 atomically consume a use with a conditional update — UPDATE coupons SET used = used + 1 WHERE id = ? AND used < total_limit (and check/insert a per-user redemption row). The DB serializes it; if 0 rows affected, the coupon is exhausted. This is the same reserve/decrement under concurrency pattern as inventory oversell.

flowchart LR
    Checkout --> Validate{Valid & eligible?}
    Validate -- yes --> Redeem[Atomic consume:<br/>used < limit AND per-user check]
    Redeem -- success --> Apply[Apply discount]
    Redeem -- exhausted --> Reject

4. Deep dives

“First 1000 uses” under a stampede: the atomic conditional increment guarantees exactly 1000 succeed; the 1001st sees used = 1000 and fails. Never read-then-write without atomicity. For extreme contention on one hot coupon, shard the counter (1000 = 10 buckets of 100) and decrement a random bucket, reconciling totals. (Hot Keys)
“One per user”: a unique constraint on (coupon_id, user_id) in a redemptions table — the DB rejects a second redemption atomically. Also gives idempotency (a retried redeem for the same user/coupon/order doesn’t double-consume).
Idempotency: key redemption by (coupon, user, order) so a retried checkout doesn’t consume two uses. (Idempotency)
Abuse: rate-limit validation attempts (brute-forcing codes), use non-guessable codes, per-user and global caps, and monitor anomalous redemption spikes (possible fraud).
Consistency: validation can be eventually consistent (cached metadata); redemption must be strongly consistent. Same split as ticketing/hotel booking.

5. Trade-offs

6. What a strong answer includes

Recognizing this is the oversell problem in disguise → atomic conditional consume, per-user uniqueness constraint, idempotency keyed on (coupon,user,order), the validate/redeem consistency split, and hot-coupon counter sharding + abuse controls. A weak answer reads the count then increments separately — races let a coupon exceed its limit.