Design a Recommendation System
Design a recommendation system like Netflix: collaborative filtering, feature engineering, and ML pipeline.
What is a recommendation system?
A recommendation system chooses a small, useful slate of items for one user from a much larger catalog. A production design normally retrieves a broad candidate set, ranks it with richer signals, applies eligibility and diversity policy, and records outcomes for future learning.
The core invariant is simple: an unavailable, blocked, or otherwise ineligible item must never reach the final slate, even through a stale cache, fallback path, or experimental model.
Recall
Retrieve broadly
Use several candidate sources so relevant, new, and long-tail products have a chance to enter the ranking pool.
Precision
Rank for value
Combine relevance, purchase intent, margin, novelty, and context without turning one proxy metric into the whole objective.
Policy
Constrain the slate
Apply inventory, safety, seller, fairness, and diversity rules after scoring and again before release.
Establish the product surface
Design an e-commerce recommender for 50 million active users and 100 million products. The homepage needs personalized recommendations; product pages need related items; email campaigns may use precomputed slates.
Ask enough questions to turn "increase engagement" into a testable system:
- Where will recommendations appear? Homepage, product detail, cart, search, and email have different intent and deadlines.
- What is the primary outcome? Optimize purchases, with revenue per session and long-term retention as secondary outcomes.
- Which events are available? Impressions, clicks, dwell time, carts, purchases, ratings, searches, hides, and returns.
- How fresh must the result be? Reflect user behavior within five minutes and inventory changes within one hour.
- What is the serving target? Keep the recommendation API below 100 ms p99 at a 15,000 requests/s peak.
- Which constraints cannot be traded away? Eligibility, privacy, category diversity, seller policy, and auditable experimentation.
Define explicit scope
The first version covers candidate generation, ranking, slate policy, event collection, training, deployment, and fallback behavior. Search ranking, ad auctions, checkout, catalog ingestion, and warehouse inventory reconciliation remain external systems with clear contracts.
An impression is part of the training contract. Without knowing what the user actually saw, clicks and purchases cannot distinguish a strong preference from missing exposure.
Architecture for the recommendation engine
You recommend items from a catalog of millions to tens of millions of users. New users and items arrive constantly, the catalog turns over quickly, and recommendations must render in the page hot path. Which architecture do you build?
Constraint: Must handle cold-start (new users and new items) and stay fresh, all at low serving latency.