Question 1

How do you prevent coupon over-use under high concurrency?

Accepted Answer

When many users simultaneously apply the last available use of a coupon, naive implementations allow more uses than the limit. Prevention options: (1) Atomic database update: UPDATE coupons SET current_uses = current_uses + 1 WHERE coupon_id = :id AND current_uses  usage_limit: DECR to undo and reject. Redis handles thousands of INCR/second safely. Use Redis as the gate; record actual usage in the database asynchronously (on order completion). (3) Semaphore with Redis: SET NX coupon:{id}:lock with a TTL. Only one request processes at a time. Lowest throughput but simplest correctness. For flash sale coupons with thousands of redemptions per second: Redis INCR is the right choice.

Question 2

How do you implement percentage vs flat discount calculation correctly?

Accepted Answer

Percentage discount: discount_cents = round(cart_subtotal_cents * discount_percent / 100). Apply max_discount_cents cap: actual_discount = min(discount_cents, coupon.max_discount_cents). This prevents '90% off' coupons from giving excessive discounts on large orders. Fixed amount discount: actual_discount = min(coupon.discount_amount_cents, cart_subtotal_cents). Cannot discount more than the order total -- avoids negative order totals. Free shipping: set shipping_cents = 0 regardless of cart total. Apply shipping discount before percentage discounts (percentage applies to subtotal, not shipping). Order of operations matters: apply shipping discounts first, then fixed amounts, then percentages. Always compute on integer cents to avoid floating-point rounding errors.

Question 3

How do you handle coupon stacking rules?

Accepted Answer

Stacking defines which coupons can be combined. Implementation: CouponStackGroup table: each coupon belongs to a group (e.g., WELCOME, SEASONAL, LOYALTY, REFERRAL). StackRule table: (group_a, group_b, is_combinable). When multiple coupons are applied: for each pair, check if their groups are combinable. If any pair is not combinable: reject one (typically the lower-value one, or show an error). Simple approach: is_stackable boolean on the coupon. Only one non-stackable coupon can be applied per order; stackable coupons can be combined freely. Most e-commerce platforms use this simple approach. Complex stacking (percentage + fixed OK, two percentages NOT OK) requires the group-based approach. Always apply the most favorable combination and communicate clearly to the user which coupons were applied.

Question 4

How do you implement per-user coupon usage limits without database bottlenecks?

Accepted Answer

Per-user limit (e.g., each user can use a coupon at most once): SELECT COUNT(*) FROM coupon_usage WHERE coupon_id=:cid AND user_id=:uid. This query must be fast -- index on (coupon_id, user_id). For high-traffic coupons: Redis SETNX coupon:{id}:user:{uid} with TTL. If the key already exists: user has used it. This is O(1) and handles thousands of requests per second. On order completion: persist the usage to the database (coupon_usage INSERT). On order cancellation: delete the Redis key and the database record to allow reuse. Edge case: if the order fails after the Redis key is set but before DB INSERT: the key expires (TTL cleanup), allowing a retry. Set TTL long enough for order processing but short enough to not block legitimate retries (e.g., 30 minutes).

Question 5

How do you build coupon analytics to measure campaign effectiveness?

Accepted Answer

Track the full coupon funnel: distributed (how many users received the coupon), viewed (user saw the coupon in UI), applied (coupon entered at checkout), completed (order with coupon was paid). Funnel: distributed -> viewed -> applied -> completed. Conversion rate at each step identifies where users drop off. Metrics per coupon: total redemptions, average order value with vs without coupon, total discount given, revenue generated (orders attributed to coupon), and incremental revenue (revenue that would not have happened without the coupon). Incremental revenue requires an A/B test: show coupon to 50% of eligible users, compare conversion rates. Without an A/B test, you cannot distinguish 'coupon caused purchase' from 'user was going to buy anyway.' Store coupon_distributed table (coupon_id, user_id, channel, distributed_at) to enable funnel analysis.

Low-Level Design: Coupon and Discount System — Validation, Stacking Rules, Usage Limits, and Analytics

Core Entities

Coupon Validation

Concurrency: Preventing Over-Use

Discount Calculation

Automatic Discounts

Analytics

Interview Tips