How would you keep an item-item similarity matrix fresh for a 2M-item catalog?

## Why the dense matrix is not an option A similarity matrix over `n` items has `n(n-1)/2` distinct pairs. At two million items that is roughly two trillion entries — even at four bytes each, terabytes of mostly meaningless numbers. And they are meaningless: two items with no common rater have no defined similarity, and in a catalog that size the overwhelming majority of pairs have exactly that. The matrix is not merely big, it is almost entirely empty. The operational question is therefore never "how do we store the matrix" but "which pairs are worth computing, and how often". ## Computing only the pairs that exist The efficient construction inverts the loop. Rather than iterating over item pairs and looking for shared raters, iterate over **users** and, for each user, emit every pair among the items that user rated. Every pair you emit has at least one common rater by construction, and every pair with a common rater is emitted at least once. For each emitted pair, accumulate three running quantities: the co-rating count, the sum of the product of the two centred ratings, and the sums of squared centred ratings needed for the denominator. At the end, one pass turns the accumulators into similarities. The cost is `sum over users of |ratings_u|^2` — quadratic in each individual profile, linear in the number of users. That distribution is brutally skewed: a user with 20 ratings contributes 190 pairs, but a bot or a super-user with 20,000 ratings contributes about 200 million on their own. A handful of such accounts can dominate the entire job. Two standard defences: **cap** each profile at a few hundred items (most recent, or highest-confidence), and **sample** pairs from profiles above the cap. Both also improve quality, since a user who rated 20,000 items is a weak signal of association anyway. ## Truncating what you keep You do not need every surviving pair either. Serving requires, for each item, its most similar neighbours — so keep the top `N` per item, typically in the hundreds. The stored table becomes `n * N` entries: two million items at 200 neighbours each is 400 million rows, which is an ordinary database. The cost of truncation is coverage. A long-tail item that appears in nobody's top-200 list can still be *scored* (it has its own list of neighbours pointing outward), but if your serving path only walks from the user's rated items outward through their neighbour lists, tail items that never appear in a head item's list become unreachable. Which direction you store matters, and if discovery of the tail is the product goal, either store both directions or keep a larger `N` for tail items. ## Why item-item can be recomputed less often than user-user This is the part interviewers actually want. It is a question about the *rate of change* of the two objects. An established item's rating column already contains thousands of ratings. One new rating moves each of its similarities by a fraction of a percent — the aggregate is dominated by history. A user's profile does the opposite: a reader with 12 ratings who rates 6 titles in one evening has changed their profile by 50%, and every one of their similarities to other users is now wrong. So the two tables age at completely different rates. Item-item is a slow-changing asset that a nightly batch keeps perfectly adequate; on a very large catalog a weekly full rebuild with nightly deltas for recently-active items is common. A user-user table is stale before the batch finishes. Critically, staleness in the item table does **not** make recommendations stale. Item-based scoring at request time reads the user's own list of rated items — fresh, including the rating they gave a minute ago — and walks the static neighbour table from there. The personalisation is computed live even though the similarities are hours old. That asymmetry is the strongest operational argument for the item-based direction on a large catalog, and it is worth stating explicitly. ## Incremental maintenance Because the construction is a set of accumulators, it is naturally incremental. Keep the co-rating counts and dot-product sums, add the contributions of new ratings, and recompute similarities only for the items touched. In practice teams mix the two: full rebuild on a slow cadence to correct drift and remove deleted items, incremental updates for hot items in between. ## New items A newly-listed title has no ratings, therefore no co-ratings, therefore no neighbours at all, and no amount of rebuild frequency fixes that — the data does not exist yet. Neighbourhood methods simply cannot place a cold item, and a real system needs a separate path for it until enough ratings accumulate. ## What a good answer sounds like Size the problem out loud (`~2e12` pairs, so no dense matrix), give the user-loop construction and its `sum |ratings_u|^2` cost, name profile capping and top-`N` truncation as the two levers, then explain the cadence argument from rate of change and finish with the point that user freshness is preserved at serving time regardless.