Design: A Recommendation System

Clarify first. For 'Top picks for you' on the home screen:

• goal: more products added to baskets from the row, without hurting order value or satisfaction;
• scale: 8,000,000 home-screen opens a day, about 278 a second at peak; 50,000 products per city, stock differs by store;
• latency: the row must be ready within 100 ms (p99) of the request;
• freshness: react to what the customer is doing in this session; new products recommendable within a day;
• constraints: only in-stock items at the customer's store; no restricted items (alcohol, tobacco) where not allowed; at most one sponsored item.

Each requirement removes options.

• 100 ms and 50,000 items rule out scoring everything with a heavy model: a two-stage design is needed.
• Per-store stock means filtering must happen at request time or per store.
• Session freshness means some features must be computed live.

Turn the goal into an ML task:

• prediction target: the probability that this customer adds this product to the basket in this session, if shown;
• task: retrieval (find ~2,000 candidates) then pointwise ranking (score them), with re-ranking for variety and rules;
• offline metrics: recall at 2,000 for retrieval; NDCG at 10 and add-to-basket AUC for ranking;
• online metric: basket additions from the row per home-screen view;
• guardrails: order value, cancellations, p99 latency, share of views with an empty or short row.

'Added to basket' is close to revenue, frequent enough to train on, and arrives within minutes.

• Clicks alone reward curiosity; purchases alone are rarer and noisier.
• A multi-task model can predict click, add and purchase together and blend them (module 12).

What to collect and how labels are built:

• impressions: every product shown, with position, request ID, model version and context (module 5);
• actions: clicks, additions, removals, purchases, joined by request ID;
• catalogue: product attributes, images, prices, stock by store;
• labels: 1 if added to basket within the session after being shown, else 0;
• sampling: keep all positives and about 10% of negatives (module 4); correct probabilities if they are used directly (module 7).

Impressions are what make negatives possible.

• Position must be logged to correct for position bias (module 7).
• Logging the served features lets training use exactly what serving saw (module 5).

Four groups (module 14):

• customer: purchase history by category, average basket, Kart Plus member, days since last order, embedding;
• product: category, brand, price, margin, popularity in this store this week, image-and-title embedding;
• customer × product: times bought, days since last bought, typical repurchase interval, embedding similarity, brand affinity;
• context: time of day, day of week, store, items in the current basket, items viewed this session.

Customer × product features dominate in grocery: people buy the same things again.

• 'Days since last bought ÷ usual interval' captures 'running low on milk'.
• Context changes intent: breakfast in the morning, snacks on Friday night.
• Session features let the row react to what was just added.

A four-stage cascade (modules 13 and 14):

• candidate sources: two-tower embedding retrieval from a per-store index; buy-again from history; item-to-item from the basket; trending in the store;
• light ranker: a small model cuts ~2,000 to ~500;
• heavy ranker: a gradient-boosted or multi-task neural model scores ~500;
• re-ranking: in-stock filter, restricted-item rules, variety (at most two per sub-category in the top ten), one sponsored slot, some exploration.

Each stage spends effort where it matters, keeping total time within budget.

• Per-store indexes make 'in stock here' a pre-filter (module 13).
• Rules live in re-ranking, where they are readable and guaranteed.

Offline and online parts:

• nightly: retrain the two-tower model and ranker; recompute item vectors; rebuild per-store indexes; compute batch features;
• streaming: session features (recent views and additions) into the online store;
• online: the ranking service, autoscaled on requests per replica (module 19), with a timeout and fallback;
• release: gate, shadow, canary, A/B (modules 15, 17 and 20).

The heavy work happens once a day; the per-request work is a lookup, a search and one batched model call.

• Vectors and indexes are rebuilt together after each retrain, so spaces never mix (module 13).

Offline, then online:

• offline: time-split evaluation on the latest week; recall at 2,000 per candidate source; NDCG at 10 and AUC for the ranker; slices for new customers, new products, each city;
• online: A/B test by customer, primary metric basket additions from the row per view, guardrails order value, cancellations, latency; at least two weeks for novelty;
• faster screening: interleaving to choose among several rankers before the A/B test (module 17).

Offline wins often do not carry over (module 16), so offline is a filter and the A/B test decides.

• Slices matter: a model that helps loyal customers and hurts new ones may still win overall.

What can go wrong, and what is watched:

• empty or short rows (stock filters too strict, index not rebuilt): share of views with fewer than 10 items;
• stale features (session stream stalled): freshness alerts and fallback rate;
• popularity collapse (feedback loop): number of distinct products receiving meaningful exposure per week;
• cold start: performance for new customers and products, with exploration slots;
• drift: festivals and promotions change baskets; nightly retraining plus event-triggered checks.

Recommenders fail quietly: a worse row still loads.

• Diversity and coverage metrics catch feedback loops that click metrics hide (module 22).
• Business guardrails catch rows that sell more snacks but fewer staples.

The questions interviewers ask about the recommendation design, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Reading an idea and explaining it are different skills.

• Each answer below is the two or three sentences an interviewer is listening for.
• The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

An idea you have only read fades in a week.

• Building it once, even in fifty lines, is what makes it yours.
• Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.