Problem Statement: Price Alerts at E-Commerce Scale
How Problem Statement: Price Alerts at E-Commerce Scale shapes architecture and interviewer follow-ups for Design Price Alert System.
Problem Statement: Price Alerts at E-Commerce Scale
A price-alert system lets a shopper subscribe to a SKU and get a trustworthy notification when its price crosses their threshold — the capability CamelCamelCamel, Keepa, Honey, and Amazon's own price alerts provide. "Trustworthy" carries the whole design: the alert must reflect the price the shopper can actually buy at right now, must arrive once per drop (never duplicated), and must not spam during a volatile listing.
Three forces shape every decision. Freshness vs noise: CamelCamelCamel shows users tolerate minutes of lag on a long-tail book but expect sub-minute alerts on Lightning Deals where they compete with bots — so the freshness SLO is not uniform. Duplicate suppression: an at-least-once notification pipeline must be idempotent, because a price-drop event that triggers two pushes destroys trust. Anti-spam: without a per-user-SKU cooldown, a listing that oscillates around a threshold spams thousands of pushes on Black Friday. And hot SKU isolation is mandatory — when an iPhone launch or Prime Day puts ten million watchers on one ASIN, a single shard evaluating them all stalls every long-tail SKU behind it.
The defining contract is the alerted price equals the buyable price: the notification must match what the shopper sees at checkout, which is hard because list price, marketplace buy-box, and coupon-adjusted prices differ. The failure to avoid from the outset is treating this as a simple "if price < threshold, send" — the real system is an idempotent, cooldown-gated, hot-SKU-isolated evaluation pipeline where the alerted price is provably the buyable one. The principle: price alerts are a trust system, judged on never double-sending, never spamming, isolating hot SKUs, and alerting the price the shopper can actually pay.
Key Highlights
- •Price alerts (CamelCamelCamel / Keepa / Honey / Amazon class) are a TRUST system: the alert must reflect the buyable price, arrive once per drop (never duplicated), and never spam a volatile listing
- •Freshness is non-uniform — sub-minute on Lightning Deals (competing with bots), minutes tolerable on long-tail; hot SKU isolation is mandatory (10M watchers on one ASIN can't stall long-tail evals)
- •The defining contract is alerted-price == buyable-price (list vs buy-box vs coupon differ); it's not 'if price < threshold send' but an idempotent, cooldown-gated, hot-SKU-isolated pipeline
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Price Alerts at E-Commerce Scale, I state invariants before components and metrics before optimizations."
- "If load doubles on section 1, I throttle ingestion before dropping evaluation correctness."