Design the Pinterest Home Feed

Understanding the problem

The phrasing sounds like the Meta or LinkedIn feed prompt, and that resemblance is the trap. There is no one you follow whose Pins get fanned out to your timeline. A Pin is an item in an interest corpus of a couple billion images, and the feed is the machinery that reaches into that corpus and finds the handful a given person wants next. So the first sentence out of your mouth sets the whole round: this is a recommendation funnel. Candidates, then ranking. Not a delivery system.

Hold that distinction, because the entire architecture follows from it. A social feed's hard problem is delivery: someone posts, you fan that write out to every follower's inbox, and you fight celebrity hot-spots and timeline storage. Pinterest barely writes anything on the fan-out path. Its hard problem is retrieval at the front: given a user, find good candidates among billions of items, fast, when there is no follow graph telling you which ones are even eligible. Embeddings and approximate nearest-neighbor search do that job. Then a multi-stage ranker sorts what retrieval found, and a diversification pass keeps the feed from collapsing into ten near-identical Pins.

The Pinterest angle

Open by drawing the funnel, and if you have done the Meta or LinkedIn feed designs, say plainly that you are NOT reusing that diagram. Meta and LinkedIn are write-fan-out: posts from people you follow, delivered to an inbox or timeline, where the work is fan-out, the timeline table, and celebrity hot-spots. Pinterest has essentially none of that. A Pin is corpus content, so the work moves to the front of the pipe. First comes candidate retrieval from a billions-item corpus via ANN over embeddings, then a multi-task ranker, then diversification. Pinterest is unusually public about this stack, so name the real pieces, two-tower retrieval, the Pinnability ranker, Sliding Spectrum Decomposition, and the round places you as someone who knows the genre.

Functional requirements

Scope it to the funnel and let the interviewer pull you wider. The core is: take a user opening the app, assemble a relevance-ranked, diverse page of Pins, and keep paginating as they scroll.

Non-functional requirements

Reason through the targets, because they explain why the funnel has the shape it does. The feed has to feel instant on app open, and it is a read-dominated system: vastly more feed requests than Pins created. That latency budget is what forces a funnel instead of one giant model. You cannot run a heavy neural ranker over billions of Pins per request, so you spend cheap compute to go from billions to thousands, then progressively more expensive compute on the survivors. Each stage is roughly an order of magnitude smaller and an order of magnitude more expensive per item than the one before it.

Relevance and freshness pull against each other and both matter. The feed should reflect what you engaged with seconds ago alongside your long-run taste, which means at least part of retrieval and ranking has to read very recent actions. New Pins have to become reachable quickly even though they have no engagement history yet, so the index has to keep ingesting new Pins within seconds. And the whole thing is multi-tenant across roughly half a billion monthly users with wildly different interest profiles, so personalization is computed fresh per request.

Estimate the load

Put down the numbers that are known, and be honest about the ones that are not. Pinterest publishes the corpus size and the top-level funnel ratio; it does not publish a full-funnel latency or QPS budget, so do not invent one. The one component number that is public is Pixie's, and it is from 2018.

• Corpus: Billions of Pins, ~500M users. The retrievable corpus is on the order of a couple billion Pins, served to roughly half a billion monthly users. There is no follow graph gating which Pins are eligible, so every Pin is a candidate for everyone, which is exactly why retrieval is the hard part.
• The published ratio: Billions to thousands. Pinterest states that retrieval narrows billions of Pins down to about a thousand or a few thousand candidates handed to ranking. The exact per-stage counts beyond that are not disclosed, so frame it as billions to thousands and resist quoting precise survivor counts you cannot source.
• Latency: Interactive, exact budget undisclosed. The feed must return fast enough to feel instant on app open, but Pinterest does not publish a full-funnel latency budget. The one public component figure is Pixie at roughly 1,200 requests per second per server at 60ms p99, and that is a 2018-era number for one retriever, not the whole feed.
• Refresh of the ranker: Retrained about twice a week. The full ranker is retrained roughly twice weekly to fight engagement decay, where a model trained on last week's behavior steadily loses accuracy. Item embeddings are precomputed offline and refreshed; the user side is computed live per request.

One number is worth deriving even though Pinterest does not publish it: the size of the item index. Take a couple billion Pins, each carrying one embedding of a few hundred dimensions stored as fp32. At 256 dimensions that is about 1KB per vector, so the raw item vectors come to roughly two terabytes before the HNSW graph adds its neighbor links on top. That doesn't fit in one machine's memory, and that fact explains two design choices. The item tower is precomputed in batch instead of per request. And the ANN index is sharded across many Manas hosts instead of living on one box. Hold the dimension loosely, it is our assumption rather than a published figure, but the order of magnitude is what forces the sharded, cached item side.

The shape that falls out: read-heavy, latency-bound, billions of eligible items with no graph to prune them, and a freshness requirement on both the items and the user's intent. That is the argument for a multi-stage retrieval-and-ranking funnel, which is what comes next.

The set-up

Core entities

Name the objects before you draw. The unusual ones here are embeddings, and the fact that a user is represented by more than one vector.

One relationship carries the design: users and Pins live in the same embedding space, so "find Pins for this user" becomes "find item vectors near this user's vectors." That single idea is what replaces the follow graph. There is no edge saying you should see a Pin; there is geometry saying it is close to your interests. Everything downstream, the parallel retrievers, the approximate-nearest-neighbor index, the pre-ranker's dot product, is machinery for computing that closeness cheaply at this scale.

API

The client surface is thin, one call that returns a page and a cursor. The interesting interface is internal, between the funnel's stages. Keep the external call boring and spend your words on the retrieval and ranking RPCs.

High-level design

Build it as a pipe that narrows. A request comes in and the candidate generators each retrieve from the ANN index in parallel. Their outputs merge into a few thousand candidates, and light-weight scoring prunes that cheaply. The Pinnability ranker scores the survivors expensively, and diversification reshuffles the top into the page that ships. The diagram codes each box by role: blue for the request and the client, violet for the model-serving stages, amber for the blending pass, green for the corpus and the embedding index.

1) Build the user, retrieve in parallel. The request arrives carrying a user id and context, device, time of day, session, and no follow graph to lean on. The two-tower retriever computes the user's embedding online from their latest roughly 100 actions, and PinnerSage supplies several medoid embeddings, one per interest cluster. Each of those vectors issues its own nearest-neighbor query against the Manas HNSW index. It returns the k closest item vectors over billions of Pins in roughly logarithmic time. Pixie walks the Pin-board graph in parallel as one more source. The billions of item embeddings were computed offline and sit in the index already, so nothing on this path re-embeds the corpus. The open question this step leaves, how you actually search billions of vectors per request without a linear scan, is the two-tower retrieval deep dive.

2) Merge and pre-rank. The generators overlap, so their outputs are deduplicated into a few thousand candidates. Each is tagged with the retriever that found it and a cheap retrieval score. Light-weight scoring, a two-tower dot product, then ranks those few thousand and keeps only the few hundred strongest. This stage earns its place on the latency budget. The full ranker is too expensive to run over thousands of items inside an interactive response. A little compute here hands it a shortlist instead of a flood. Nothing fancy decides relevance yet. The pre-ranker is deliberately blunt, and the cost pressure that makes it necessary is the same pressure the ranker deep dive unpacks when it explains why the heavy model moved onto GPUs.

3) Rank for real. The few hundred survivors hit the Pinnability ranker. It encodes the user's realtime action sequence with a transformer: the latest roughly 100 actions, each represented by the engaged Pin's GraphSage embedding plus action type and timestamp. It crosses features explicitly with DCN-v2, and scores every candidate on repin, click, and hide at once through separate task heads. It runs on GPUs because the transformer added real latency, and it is retrained about twice a week so it does not drift as behavior shifts. Most of the relevance decision is made here, from per-Pin probabilities that get blended into one score. Why it predicts several actions instead of one click, and why the sequence is read in order, is the ranker deep dive.

4) Diversify and ship. A relevance ranker left alone will stack ten near-identical chairs at the top because each one scores well on its own. Sliding Spectrum Decomposition re-ranks the top of the list. Each placed Pin's value is its relevance minus a penalty for how much it resembles the Pins already chosen above it, in visual, text, and graph embedding space. The page, a few dozen Pins, then goes back to the client with a cursor for the next request. Scroll again and the whole funnel reruns with the now-updated action sequence, so a save you made ten seconds ago shifts what you see next. How the diversity penalty is tuned against relevance without flattening a genuinely deep interest is the diversity deep dive.

Technology choices

Every box is a category until you name a real system and defend it. Pinterest is public about these, so use the real names and be ready for the trade-off behind each.

• The retrieval index is an HNSW approximate-nearest-neighbor engine served on Manas, Pinterest's in-house retrieval system. HNSW stands for Hierarchical Navigable Small World. The vectors are wired into a layered graph where each node links to its nearest neighbors. A query hops greedily downhill toward its closest matches, answering a nearest-neighbor lookup over billions of vectors in roughly logarithmic time. You reach for an ANN index because the exact alternative, comparing the user vector against every item vector, is a linear scan of billions per request that no interactive latency budget survives. Manas runs two modes: a batch mode over static precomputed indices, and a realtime mode backed by an LSM engine fed from a stream. Expect a freshness probe: how does a brand-new Pin become reachable? The realtime mode answers it, since it ingests new vectors within seconds instead of waiting for the next batch build.
• The candidate generators run in parallel and stay heterogeneous, several different retrievers rather than one. Two-tower embedding retrieval carries the bulk of coverage. PinnerSage issues one nearest-neighbor query per interest cluster so distinct tastes don't average into mush. The older Pixie graph walk brings a different paradigm: proximity over the Pin-board graph instead of in vector space. The reason to run all of them is recall: each retriever has its own blind spots, and the union of their candidates beats whatever the single best one returns alone. The architecture makes this cheap to extend, since a new retriever is just one more parallel source whose candidates join the merge before scoring. If an interviewer asks why one strong two-tower model isn't enough, answer that no single retriever covers every way a Pin can be relevant. The merge closes the coverage gaps.
• The two rankers are a two-tower dot-product pre-ranker and a transformer-encoder plus DCN-v2 full ranker served on GPUs. The split comes from the same cost asymmetry the funnel is built around. A cheap model can afford to look at thousands of candidates, an expensive one only at a few hundred. So the cheap one runs first to protect the expensive one. Name the lineage, since it shows the cost climbing stage by stage. Gradient-boosted trees did early lightweight ranking. A two-tower DNN dot product took over pre-ranking, and the transformer-plus-DCN-v2 network became the full ranker. The probe here is usually about the GPUs. The transformer added enough latency that CPU serving stopped being viable. That's why the light-weight scoring stage has to exist, to keep the candidate set small.
• Diversification is Sliding Spectrum Decomposition in the blending stage, scoring similarity between Pins with their visual, text, and graph embeddings. It's written as an explicit objective instead of a heuristic cap like "no more than three chairs in a row." Each candidate's value is its relevance minus a penalty for overlapping the Pins already placed. That matters because category caps lean on labels that are coarse and often wrong, while an embedding penalty catches look-alikes that share no taxonomy at all. The trade-off it hands you is a single dial: lean too hard on the diversity penalty and you bury genuinely relevant Pins, lean too little and the feed clumps into near-duplicates. If asked how you'd tune it, say you measure both relevance and on-page variety and move the dial against live engagement. The right setting is product judgment rather than a fixed constant.

The Pinterest angle

The round turns on the retrieval stage, so go there first and stay specific. A generic answer treats "get candidates" as a throwaway box and spends its time on caching the rendered feed. Pinterest's interviewers built the opposite system: rendering is the easy part, and retrieval from billions of items with no follow graph is the hard part. Name the two-tower split (user tower online, item tower precomputed), name HNSW on Manas as the ANN engine, and explain why several parallel generators beat one. That is the difference between an answer that sounds like Pinterest and one that sounds like a cached news feed.

Potential deep dives

The signal lives in the stages. An interviewer here drives at how retrieval works, why ranking is multi-task, how diversity gets enforced, and the two failure modes that catch people: keeping embeddings comparable across model rollouts, and cold-start.

1) Two-tower retrieval: how do you search billions of Pins per request?

This is the heart of the design. The question underneath it: with no follow graph, how do you find a few thousand good Pins out of billions, fast, for a specific person? Work it as a progression.

The Pinterest angle

Say "user tower online, item tower precomputed" out loud; it is the line that shows you understand two-tower retrieval rather than reciting it. That split is the design. Billions of item vectors are too expensive to compute per request and change slowly, so they are batched and cached, while the user's intent changes by the second and must be computed live. Follow it with "and the search is approximate-nearest-neighbor, HNSW on Manas, not a brute-force dot product," and you have named both halves of why this scales. Hand-waving "embeddings and a vector DB" leaves the interviewer unsure you know where the cost is.

2) The Pinnability ranker: why multi-task, and why a transformer?

Retrieval found a few thousand plausible Pins. Ranking decides their order, and this is where Pinterest spends real compute. Two design questions drive it: what does the model predict, and what does it read.

Start with what it predicts. A single "will they click" score is a weak target on Pinterest. The action that matters most is a save (a repin), and you also want to avoid showing things people hide. So Pinnability is multi-task: one network with several heads predicting repin/save as the primary objective, plus click, hide, and other engagement classes. The heads share a representation. Signals that predict a save also inform a hide, and learning them together is cheaper and more accurate than training separate models. The final ordering is a weighted combination of the head probabilities; the exact weights are proprietary, so describe the mechanism (a weighted blend of repin, click, and negative-hide probabilities) rather than inventing the coefficients.

The Pinterest angle

When the interviewer asks what the ranker optimizes, do not say "engagement"; name the heads. Repin as the primary objective, plus click, plus hide as a negative signal, all from one multi-task model. That specificity matters because it reflects an actual product judgment: a save is worth more than a click, and a hide is a cost, so a single click-through model would rank the wrong things. If they push further, reach for the realtime action sequence (the latest ~100 actions, each as a Pin embedding) and why it's a transformer. That part makes the feed react inside a session, on top of your long-run profile.

3) Diversity: how do you stop ten near-identical Pins?

A ranker that scores relevance well will happily fill the top of the feed with ten almost-identical chairs, because each one is individually relevant. That is a worse experience than a few good chairs and some variety, so diversification earns its own stage.

4) Keeping embeddings comparable across model rollouts, and cold-start

Two failure modes separate a senior answer here, and both are easy to miss because they only bite in production, not on the whiteboard.

The first is embedding version sync. The user tower runs online and the item embeddings were precomputed offline, and they must live in the same space for the dot product to mean anything. Ship a new embedding model and the two can drift out of alignment. The item index might still hold old-model vectors while the user tower computes new-model ones. A nearest-neighbor query across two different spaces returns garbage. The fix is to attach version metadata to the embeddings and the ANN hosts, so a query is only ever matched against item vectors from a compatible model version during a staged rollout. You roll the index and the tower forward together, never letting a request mix versions. Skipping this is the kind of bug that silently tanks relevance during a deploy and is hard to trace.

• Cold-start, new user. With little or no action history, the user towers and PinnerSage have nothing to cluster, so the personalized retrievers are weak. Fall back to popular and trending Pins, and lean on the onboarding interests the user picked at signup, conditioning retrieval on declared interests until real behavior accumulates. Each action they take feeds the realtime sequence, so personalization ramps within the first session rather than waiting for a nightly job.
• Cold-start, new Pin. A freshly created Pin has no engagement history, so any model that relies on past clicks cannot rank or even retrieve it. The escape is content-based embeddings: PinSage-style graph and visual signals give a brand-new Pin a vector from its image and its place in the Pin-board graph, no engagement required. Push it into the realtime ANN index (the streaming mode, fed within seconds) and it becomes retrievable almost immediately instead of waiting for the next batch index build.
• Why both matter in the round. They are the questions that show you have thought past the happy path. A funnel built only for established users looking at established Pins falls short for a growing product, and an interviewer who senses you have only the steady-state story will go straight here.

The Pinterest angle

If you have a minute left, spend it on embedding version sync; almost no one raises it, and it is exactly the kind of thing Pinterest's team hits in production. The setup is a gift for it: an online user tower and an offline item index that must share a space. Try saying "I'd version the embeddings, only match a user vector against item vectors from a compatible model version, and roll the index and tower forward together." That signals you've shipped a retrieval system. Cold-start is the more expected follow-up, so have the content-embedding answer for new Pins ready too, but the version-sync point is the one that lands as senior.

What is expected at each level

That is a lot of surface. How much you have to land depends on the level the loop is calibrated for, and at senior this design round is reported to set that level.

IC14 (mid-level)

Get the funnel right and resist the fan-out reflex. Reach a working end-to-end shape: candidate generation, retrieval, a ranking stage, and diversification, in that order. Say out loud that this is a recommendation funnel, so you never draw a timeline or an inbox. The non-negotiable is that retrieval is the hard part and it uses embeddings plus approximate-nearest-neighbor search over a billions-item corpus. The deeper modeling can surface in conversation.

IC15 (senior)

Depth now, and this is the level the round most often decides. You drive the two-tower split unprompted, user tower online, item tower precomputed, retrieval via HNSW ANN, and you justify the multi-stage funnel as a latency-versus-cost progression. You explain why ranking is multi-task (repin primary, click, hide) and why a single click model would rank the wrong things, and you reach diversification as its own objective rather than a category cap. The bar is a near-complete funnel where you found the retrieval and ranking structure yourself.

IC16+ (staff and beyond)

Depth leads as the scope widens. Expect the realtime action sequence and why the ranker is a transformer over it. Reason about SSD as relevance minus a spectral penalty over embeddings. Raise and solve the embedding version-sync problem without prompting, and handle cold-start for both new users and new Pins. You reason about how the system degrades, a stale ranker, a drifting index, a hot interest, and you hold the wheel while the interviewer pushes from the edges. The bar is that every stage is a deliberate, defended choice and the funnel is yours, not a recited diagram.