Feed ranking

Ranking decides which candidate posts appear first. A chronological feed sorts by time. A ranked feed scores each candidate with signals such as affinity to the author, recency and media type, then removes repeats and over-represented authors. It runs in stages, so the expensive scoring only touches a short list.

The big idea

Think of a hiring funnel. First, screen many résumés quickly. Then score the shortlist carefully. Last, make sure the final slate isn't all from one company. Each stage handles fewer items than the one before, so the expensive work stays affordable.

The picture holds for the stages. It breaks for the signals, because a feed score predicts what a person will engage with. It is not a judgment of the person.

Walking through it

Here is one feed load, traced through the four stages:

1. Candidates   a few hundred posts from the timeline cache and celebrity lists
2. Features     affinity to author, age of post, media type, seen state
3. Scoring      a weighted formula or a trained model, one score per post
4. Re-ranking   limit repeats from one author, drop blocked authors

Stage 1 keeps the set to hundreds, not millions. That is what makes the scoring affordable. Stage 4 is where product rules live. A common one is "no two posts from the same author in a row". Keep such rules explicit, because they change what users see.

The recommender systems page covers the model side. In an interview, describe the stages and say that ranking runs asynchronously to precompute scores, or lightly at read time on a small candidate set. Don't design a model architecture unless asked.

Seen state

Users hate seeing the same post again after a refresh. Track a per-user seen watermark, or keep a short Bloom filter or LRU list of recently shown post IDs. Filter at hydration time. It doesn't need to be perfect, because occasional repeats are acceptable. A ranked feed also uses seen state as a negative signal, so the model stops resurfacing yesterday's viral post.

Common mistakes

• Scoring the whole corpus. Ranking millions of posts per load is far too costly. Narrow the candidates first.
• Skipping the diversity step. Without it, one friend can fill the whole screen.
• Skipping seen state. A refresh then shows the same posts again, and users notice.
• Designing the model before the pipeline. Interviewers want the stages first.

Check yourself

1. Why rank a few hundred candidates instead of every post?

   Scoring costs time per post, and candidate generation has already narrowed the set. Scoring everything would be far too expensive per load.

2. What is seen state for?

   It hides posts the user already saw, so a refresh doesn't repeat them. Occasional repeats are acceptable.

Key takeaways

• Ranking runs in stages: candidates, features, scoring, then diversity.
• Keep the expensive scoring on a short candidate list.
• Diversity and blocking rules belong in a final stage, and they should be explicit.
• Seen state stops repeats and gives the ranker a negative signal.

Further learning

Next: timeline consistency, deletes and blocks, which covers posts that were deleted, blocked or muted after fan-out.