Design Gift Card System

Problem Framing and Gift Card Scope

A gift card system is a stored-value liability ledger with credential-based access — Amazon, Starbucks, and Target all treat gift cards as money the company owes, not as discount coupons. The framing that wins the interview separates three money movements: issuance (money enters the platform when a card is bought), redemption (money leaves at checkout when a card is spent), and breakage (unredeemed balance the company eventually recognizes as revenue after expiry). The cardinal rule is that the system must never double-spend a dollar — not across partial checkouts, not across refunds-to-credit, not across concurrent redemption attempts on the same card.

Open with three invariants, because stating them up front separates a serious answer from 'just store the balance in Redis'. First, every dollar of liability is backed by an append-only ledger entry — the balance is a projection of immutable entries, never a mutable number you overwrite. Second, redemption is hold -> capture -> release, exactly like a payment authorization — you reserve the amount, commit it on order placement, and release it on abandonment, never a direct balance decrement without idempotency. Third, codes are credentials — brute-force guessing and enumeration are first-class threats, not afterthoughts.

Scope in: digital and physical issuance, balance inquiry, partial redemption, store-credit refunds, expiration, region and currency rules, and fraud scoring. Scope out (integrate, do not build): the full payment gateway, loyalty-point accrual, and the tax engine — mention the hooks only. The nuance to voice is that Starbucks loads cards into a wallet while Amazon allows split-tender checkout (part gift card, part credit card), and a good design handles both without ever conflating promo-code semantics with stored value — a promo code is a discount rule, a gift card is money the company holds in trust.