Design Loyalty Program

Problem Statement: Design Loyalty Program

A loyalty program is a financial subsystem that issues, stores, and settles a private currency — points — against real money the customer spends. Treat it that way and you out-perform every candidate who reaches for a marketing-rewards mental model.

At its core the system does three things. It earns points when an order settles. It tracks a per-member balance that must never go negative. And it redeems points against a catalog of offers without ever letting two concurrent carts spend the same point twice. Starbucks proved the mobile-first version: you order ahead, Stars post after the card is captured, and you redeem at the POS by scanning a barcode that reconciles to a central wallet within minutes even when the store Wi-Fi drops. Sephora layers tiers on top — Insider, VIB, and Rouge unlock multipliers and gifts based on rolling spend. Amazon ties the earn rate to category and Prime status.

The interviewer is listening for one decision early: do you model points as an immutable, append-only ledger, or as a mutable integer you increment and decrement? The mutable column is the trap. The moment a refund, a chargeback, or a duplicate event arrives, you cannot reconstruct how the balance got where it is, and finance cannot audit it. We anchor on settled-order accrual, double-entry ledger rows, and a redemption path that holds points before it commits them. The trade-off is more storage and more write amplification per transaction; the payoff is that every point traces back to the order that minted it.

The failure that defines the design: a member redeems 500 points for a \$5 reward, then returns half the order. The earn that funded those points is now partially reversed. Clawback ordering — debit the reversed earn, decide whether the already-spent reward survives, and decide whether the balance may go temporarily negative — is the question that separates a real answer from a sticker chart.