Offline Recommendation

Some recommendations do not have to be computed while the user waits. If a homepage shelf changes once a day, you can score it overnight for every user, write the results to a key-value store, and serve the page with a single lookup. That is offline recommendation: the ranking work happens in a batch job, ahead of the request.

How the batch path works
A scheduled job reads the interaction table, refreshes user and item representations, scores candidates per user, and writes the top few hundred item ids per key into a store the serving tier reads — Redis, Cassandra, or a cached table. Serving then costs one fetch, so the expensive model runs on a cluster with no latency budget at all.

What it buys and what it costs

• Cheap, predictable serving — a lookup per request whatever the model's size; an implicit ALS factorisation over the full user-item matrix is affordable here and impossible per request.
• Staleness — the list reflects behaviour as of the last run, so anything a user did since is invisible to it.
• No row for new users — anyone created after the batch ran has nothing stored, which is why batch shelves are paired with an online fallback.

Where it still wins
Slow-moving surfaces — weekly digests, email campaigns, the "related items" strip on a product page — are better precomputed, and most production systems run both paths: batch for the stable component, online scoring for whatever must react inside the session. Note that this is a question of where computation happens, not of how a system is measured, which is what offline evaluation means.