Design an E-Commerce Recommendation System

Recommendation engines drive roughly 35% of Amazon's revenue and save Netflix an estimated $1 billion per year by reducing churn. When you see "customers who bought this also bought," that is a recommendation system at work. Designing one means building a pipeline that collects user behavior, learns preferences, and serves personalized product suggestions in real time.

Functional

User activity tracking: Collect every signal of user intent: purchases, product clicks, page views, search queries, likes, dislikes, and wishlist additions. Each event type carries different weight. A purchase is a much stronger signal than a page view. The system must ingest billions of events per day and associate each one with a user ID and timestamp.

Recommendation systems are unusual because the read path (serving recommendations) is fast and cheap, but the write path (ingesting events and training models) is the bottleneck. The capacity math reveals where to invest engineering effort.

Traffic

Event ingestion: 100M daily active users, each generating roughly 20 events per session. That is 2 billion events per day, or about 23K events per second on average. During peak hours (evening, flash sales), expect 3-5x: 70-115K events per second. Black Friday can push this to 10x baseline.

The recommendation system exposes two main API surfaces: an event ingestion API for collecting user behavior and a recommendation serving API for returning personalized results. The design choices reflect the asymmetry between writes (high volume, tolerant of latency) and reads (moderate volume, latency-critical).

Event Ingestion API

1POST /api/events
2Body: {
3"user_id": "u_12345",
4"event_type": "purchase", // purchase, click, view, search, like, dislike, wishlist
5"item_id": "item_67890",
6"context": {
7"session_id": "sess_abc",
8"device": "mobile",
9"page": "product_detail",
10"keyword": null // populated for search events
11},
12"timestamp": "2026-03-14T10:30:00Z"
13}
14Response: 201 Created

The recommendation system needs three distinct storage tiers: a high-throughput append-only store for raw events, a structured store for user and item features, and a low-latency cache for serving pre-computed recommendations. No single database handles all three well.

Activity Event Store

1- Append-only event log (Kafka topic: user_events)
2- Sinks to columnar store for batch analytics
3CREATE TABLE activity_events (
4event_id UUID PRIMARY KEY,
5user_id VARCHAR(64) NOT NULL,
6item_id VARCHAR(64) NOT NULL,
7event_type VARCHAR(20) NOT NULL, - purchase, click, view, search, like, dislike, wishlist
8context JSONB, - session_id, device, page, keyword
9created_at TIMESTAMP NOT NULL
10);
11CREATE INDEX idx_user_events ON activity_events(user_id, created_at DESC);

The architecture separates three concerns: event ingestion (collecting behavior), recommendation computation (generating suggestions), and recommendation serving (returning results fast). Each scales independently.

Components

Two core flows drive the system: collecting user behavior (write path) and serving recommendations (read path). A third flow, model retraining, runs in the background and connects them.

Write Path: Activity Ingestion

The recommendation engine is the heart of the system. It combines multiple strategies, each with different strengths, into a unified ranking that balances relevance, diversity, and freshness.

Collaborative Filtering

Every design decision in a recommendation system trades off between competing goals. Understanding these trade-offs, and articulating them clearly, is what separates a strong interview answer from a surface-level one.

Batch vs. Real-Time Processing

Batch processing (hourly/daily): Recomputes recommendations for all users. The model trains on the full dataset. Recommendations are comprehensive and accurate because the model sees all available data. The cost: recommendations are stale for up to the batch interval. A user who purchased a laptop 30 minutes ago still sees laptop recommendations until the next batch runs.

A recommendation system has an unusual failure property: it can fail silently. Unlike a payment system where failures are immediately visible, bad recommendations look like a subtle decline in engagement that takes days to detect. This makes monitoring and fallback strategies critical.

Recommendation Service Outage

The entire recommendation service goes down. Every product page, homepage, and cart page calls the recommendation API. Without a fallback, those sections are empty, reducing engagement and revenue.

Recommendation systems are one of the fastest-evolving areas in machine learning. The basic architecture described above handles most use cases, but several advanced techniques can significantly improve quality.

Context-Aware Recommendations

Current design uses static user features. Context-aware systems incorporate time-of-day, device type, location, weather, and current session behavior. A user shopping on a phone during lunch break has different intent than the same user on a desktop at night. Morning queries on mobile lean toward quick purchases (coffee pods, phone chargers). Evening desktop sessions lean toward research purchases (furniture, electronics). Incorporating these signals into the ranker produces meaningfully better recommendations.