Netflix's Recommendation Architecture

The problem

Personalisation drives a very large share of Netflix viewing, and the home page is entirely computed — rows, their order, the titles in them, and even the artwork shown for each title. All of it must render in the time it takes a television to draw a screen, for a catalogue and member base of enormous size.

The naive approach — score every title for every member on request — is impossible. The naive fix — precompute everything nightly — cannot react to what the member did five minutes ago.

The architecture, as published

Netflix's engineering blog describes a three-layer split, and the split itself is the reusable idea:

Offline. Batch computation over the full history: model training, similarity matrices, candidate generation. Runs on a schedule, has hours to work, has no latency constraint at all. Results are materialised into stores the online layer can read cheaply.

Nearline. Event-driven incremental updates. When a member finishes an episode or rates something, jobs update the affected precomputed structures within seconds to minutes. This is the layer that gives the system a memory of recent behaviour without paying full recomputation.

Online. The request path. It assembles and lightly re-ranks precomputed candidates using immediate context — device, time of day, what the member is doing right now. Strictly bounded latency, with a fallback to precomputed results if a component is slow.

Why the split works

It matches computation to its latency budget. Expensive, stable computation goes offline; cheap, context-sensitive computation goes online; the awkward middle — "recently changed, not worth a full rebuild" — goes nearline.

The pattern generalises far beyond machine learning. It is CQRS with three tiers of freshness, and the same shape appears in search indexing, fraud scoring, pricing and feed ranking.

The details worth stealing

Graceful degradation is designed in. If the online ranker is slow or unavailable, the page still renders from precomputed rows. A personalisation failure produces a less relevant home page, never a blank one — the system's worst case is a worse product, not an outage.

Artwork is personalised too, using contextual bandits, which is an unusually clear example of treating a UI asset as a ranked decision rather than a static file.

Everything is an experiment. The architecture exists to support continuous A/B testing, which means multiple model versions must be servable simultaneously and attributable — a requirement that shapes the whole system and is easy to retrofit badly.