Problem Statement & Context
What we are building and why it matters
Problem Statement & Context
A product recommendation engine selects and ranks items for each user across home feed, product pages, cart, and email. It turns sparse behavioral signals into personalized suggestions that lift conversion, average order value, and retention. Unlike search (user-initiated), recommendations must infer intent from context and history.
What it must handle
Massive catalogs (100M+ SKUs, frequently updated); billions of impressions/day; real-time feedback loops (clicks, carts, purchases); cold start for new users and items; exploration vs exploitation while preserving diversity.
The journeys
- Buyer: open app → personalized home modules → view a product → "you may also like" updates → add to cart → cross-sell → checkout → post-purchase recs.
- Merchandiser: define rules (boost, suppress, seasonal) → launch experiments → monitor CTR, CVR, revenue/impression.
The load-bearing idea: a two-stage funnel plus a feature store
Recommendations are fundamentally a two-stage funnel under a hard latency budget: cheap candidate generation narrows 100M SKUs to ~1k–10k in tens of milliseconds, then an expensive ML ranker scores only those candidates with real-time features — because you can never run the heavy model over the whole catalog within a P99 of 120 ms. The feature store is the seam that makes this work: it bridges the offline world (where models train on logged events) and the online world (where serving fetches features in <20 ms). Almost every later decision — the online/offline split, the policy layer, the graceful fallbacks — flows from "retrieve cheaply, rank expensively, on features served fast."
Scale anchors
200M DAU, 10B impressions/day (~115K rps avg, ~920K peak), 1B clicks/day, 50M purchases/day, 5–8× sale spikes. These drive latency budgets, feature-store sizing, and model-serving throughput.
Key Highlights
- •A product recommendation engine selects + ranks items per user across home/PDP/cart/email — turning sparse behavioral signals into personalized suggestions (lift conversion/AOV/retention); unlike search (user-initiated), recs INFER intent from context + history
- •Must handle massive catalogs (100M+ SKUs), billions of impressions/day, real-time feedback loops (clicks/carts/purchases), cold start (new users/items), exploration vs exploitation + diversity
- •The load-bearing idea: a TWO-STAGE FUNNEL under a hard latency budget — cheap candidate generation narrows 100M SKUs to ~1k-10k in tens of ms, then an expensive ML ranker scores only those (you can't run the heavy model over the whole catalog within P99 120ms)
- •The feature store is the seam: it bridges offline training (models on logged events) + online serving (features in <20ms); almost every decision (online/offline split, policy layer, fallbacks) flows from 'retrieve cheaply, rank expensively, on features served fast'; anchors 200M DAU, 10B impressions/day (~115K rps avg, ~920K peak), 5-8× spikes
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate candidate generation from ranking for scalability."
- "Recommendation latency and relevance are both first-class requirements."
- "Cold start coverage must be explicit from day one."