Data & analytics · Advanced

Recommendation system

Candidate retrieval then ranking online, nearline feature updates, and offline training with precomputed fallbacks.

Every part, and why it is there

Viewers

Open the home page and expect rows that feel picked for them, within a few hundred milliseconds.

API gateway

Routes home-page requests and records which user and device is asking.

Home page service

Builds the page: asks for candidates, gets them ranked, and falls back to precomputed rows if anything is slow. It also logs what was shown, which is training data.

Precomputed recs

Recommendations calculated offline per user. They are a bit stale, but always available instantly, which makes them the safety net.

Candidate generation

Picks a few hundred plausible items out of millions, cheaply, by finding items whose embeddings sit close to the user’s.

Embedding index (ANN)

Approximate nearest-neighbour search over item embeddings: trades a little accuracy for answers in milliseconds instead of comparing against every item.

Ranker

A heavier model that scores each candidate with rich features (recent watches, time of day, device). Too expensive to run on millions of items, perfect for hundreds.

User & item features

Low-latency lookup of the features the ranker needs, refreshed by the nearline path within seconds of new activity.

Impressions & plays

What was shown and what was watched. The same events feed real-time features and the next model training run.

Nearline updater

Updates features such as “just watched” seconds after it happens, so the next page load reflects it without waiting for a nightly job.

Offline training

Retrains models on days of history and recomputes the fallback recommendations. Hours-long jobs that never touch a live request.

Interaction history

The full record of impressions and plays used to train and evaluate models.

Asked in interviews at

  • meta
  • disney
  • mastercard
  • amazon

Learn more

All system design examples