Machine coding round
E-Commerce Coupon Engine Coding Interview Problem
What this interview round tests
The coupon engine is the pricing-rules round: a low-level design problem asked constantly at e-commerce companies because every checkout has one, and every one of them is a minefield. Percentage versus flat discounts, minimum cart values, category restrictions, caps, stacking rules, expiry — and a redemption that must burn exactly once even when the request is retried.
Interviewers ask it to see two things. First, whether you encode rules as data evaluated in one place, or as nested ifs that the inevitable "now add one more coupon type" extension shatters. Second, whether you notice that applying a coupon is a state-changing operation with money attached: order of application changes totals, rounding must be pinned down, and idempotency is not optional.
The scenario
You are handed the coupon service of a checkout backend. Coupons have eligibility conditions, discount logic, and usage limits; carts come in, discounted totals go out. The shape is right, and the test suite disagrees with almost every number.
Ineligible coupons apply anyway, expired and exhausted coupons still discount, stacking rules are ignored so combinations produce absurd totals, caps and rounding drift by a rupee here and there, and a retried redemption burns a single-use coupon twice. Your job is to make eligibility, computation, and redemption exact.
What you’ll practice
- Eligibility evaluation: minimum cart value, categories, user constraints, expiry
- Discount computation: percentage vs flat, caps, and explicit rounding
- Stacking rules: which coupons combine, and in what order they apply
- Idempotent redemption: a retried apply never double-burns a coupon
- Usage limits: per-coupon and per-user counts enforced exactly
- Money discipline: integer minor units and totals that always reconcile
How to approach it
Separate the three phases and keep them honest: eligibility (may this coupon apply to this cart at all?), computation (what is the discount, capped and rounded, applied in a defined order?), and redemption (record the burn, exactly once). Most broken implementations smear these together, so a failed computation half-burns a coupon or eligibility gets checked after money moved.
Evaluate every rule in one policy point so adding a coupon type is data, not surgery. Fix an application order for stacked coupons and round at defined points in integer minor units — the tests check totals to the exact unit. Key redemptions idempotently so the same request replayed returns the original result.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
What makes a coupon system a good LLD interview question?
It grades extensibility under change. The initial spec is easy; the follow-up ("add a buy-one-get-one type", "cap combined discounts at 40%") is the real test. Rules encoded as data behind one evaluation point survive it; hard-coded branches do not.
Why does idempotency show up in a pricing problem?
Because applying a coupon mutates state — usage counts and single-use burns. Checkout requests get retried by clients and gateways, and a coupon that burns twice on a retry is a real production incident. The tests replay redemptions to check exactly this.
How is the problem graded?
A bundled test suite runs carts through eligibility, stacking, cap, rounding, and retry scenarios and checks totals to the exact minor unit. You fix the service layer until it goes green, in the browser workspace or locally in Java, Python, or C++.