Design a coupon / promo-code service that a large e-commerce checkout calls to validate a code, decide the discount, and atomically record a redemption when an order is placed. Marketers create campaigns; shoppers type a code at checkout (think a big online-retail checkout on a sale day).

Operating context. A campaign mints codes in two shapes: a single shared code (e.g. SALE20, one string usable by millions) and unique per-user codes (a large batch minted up front). Each campaign carries rules — validity window, per-user cap, a global redemption cap, minimum cart value, eligible product categories, first-order-only. Checkout traffic is read-heavy for validation (a shopper may re-validate on every cart edit) and write-critical for redeem. Expect 20000 validate/sec at steady state and 80000/sec during a flash sale, against a much smaller ~2000 redeem/sec. The dangerous case is a single popular code with a global cap of, say, 10000 uses getting hammered by tens of thousands of concurrent carts — you must never over-issue past the cap, and a shopper must never silently double-spend a one-per-user code.

Out of scope. The campaign-authoring UI, the discount MATH beyond returning an amount/percent, the payments/settlement flow, marketing analytics dashboards, and multi-currency FX. Assume the order service calls you and owns the cart total.

What to produce. A high-level architecture covering: the validate and redeem request paths and their API shapes; the data model and how campaigns, codes, and per-user redemption records are partitioned; how a shared code is generated/stored versus a batch of unique codes; the rules-engine that evaluates eligibility; how redeem stays atomic under contention against both the global cap and the per-user cap; the caching strategy for hot validate traffic; and how you resist abuse (guessing, sharing, replay). Sketch the components and the request flow; checkpoints will probe the redeem race and the cap math specifically.