The Ranking Service

In one line: Lesson 1 argued a newsfeed is two problems, and this is the second one — the part with no clean engineering answer, which the design correctly isolates into its own service.

What it does

The newsfeed ranking service consists of algorithms working on various features, such as a user's past history, likes, dislikes, comments, clicks, and many more. These algorithms also:

• Select "candidate" posts to show in a newsfeed.
• Eliminate posts including misinformation or clickbait from the candidates.
• Create a list of friends a user frequently interacts with.
• Choose topics on which a user spent more time.

Those four bullets are four different stages, and treating them as one service hides the funnel

Read them again — they are not four features of one algorithm. They are stages in a pipeline, and they must run in this order for the pipeline to be affordable:

1. RETRIEVAL     "select candidate posts"           thousands -> hundreds
2. FILTERING     "eliminate misinformation"         hundreds  -> hundreds
3. FEATURES      "friends you interact with"        computed per candidate
                 "topics you spend time on"
4. SCORING       rank by predicted relevance        hundreds  -> 200

The ordering is not stylistic. Lesson 8's step 3 must produce a bounded candidate set before scoring runs, because the design itself says a model evaluates "thousands of features" per item. You cannot afford that over an unbounded corpus.

Cheap operations FIRST, on many items.
Expensive operations LAST, on few items.

Every large-scale ranking system is this funnel — search engines, recommenders, ad auctions. The names differ; the shape does not. Retrieval is cheap and approximate, ranking is expensive and precise, and the funnel exists so the expensive stage sees a small input.

Naming it as a funnel rather than a service is the single most useful reframing available here, because it tells you where to spend: widening retrieval improves recall; improving the model improves precision, and they are different investments.

The worked example

Assume there are 10 posts in the database published by 5 different users. We aim to rank only 4 posts for Bob:

1. Features such as likes, comments, shares, category, duration are extracted from each post.
2. Based on Bob's previous history, relevance is calculated via ranking and machine learning algorithms.
3. A relevance score from 1 to 5 is assigned.
4. The top 4 posts are selected.
5. They are presented in decreasing order of score.

Post scores:  5  4  3  2  |  discarded: 1, 1, 2, 1, 3, 2
Bob's feed:   [5] [4] [3] [2]

A 1-to-5 integer score cannot rank hundreds of candidates

The example works with 10 posts and a 1–5 scale. Scale it to Lesson 2's arithmetic — ~2,750 candidates per day — and the scale collapses.

With 2,750 items and 5 possible scores, roughly 550 posts share each score. The ranking has told you almost nothing about ordering within a bucket, and the feed is effectively random inside each tier.

Real systems predict a continuous value — usually a probability:

P(user clicks)  ·  P(user comments)  ·  P(user shares)  ·  P(user hides it)

combined into a single score. Continuous values order arbitrarily many items without ties.

Two further points the example's simplicity hides:

Ranking is multi-objective. You are not predicting one thing. Engagement, time spent, and negative feedback pull in different directions, and the weighting between them is a product decision, not a modelling one — it is where "optimize for engagement" versus "optimize for well-being" actually lives.

Predicted engagement is not value. A model trained purely on clicks learns that outrage and clickbait perform well — which is precisely why bullet two of the service description has to eliminate clickbait as a separate filtering stage. The filter exists because the objective is wrong, and that is worth stating plainly rather than treating filtering as an add-on.

The cost

Newsfeed ranking with machine learning algorithms is a computationally intensive task. This service consists of big data processing systems that might utilize specialized hardware like GPUs and TPUs.

According to Facebook: "For each person on Facebook, we need to evaluate thousands of features to determine what that person might find most relevant."

This is the expensive tier, and Lesson 3's estimate has no line for it

Put the two together. Thousands of features per post, hundreds of candidates per user, 500 million users, refreshed continuously.

500M users x ~500 candidates x ~1,000 features = ~10^14 feature evaluations/day

Order-of-magnitude and the point stands: this is the system's dominant compute cost, and Lesson 3's estimation — which sized 8,000 web servers from a request rate it had already disproved — never mentions it.

That is the same failure as that building block, where the standard template measured storage and bandwidth while GPU inference was the entire bill. Here it measures request handling while ranking compute is the bill.

Three consequences that shape the architecture:

Ranking must be asynchronous. You cannot run 500 candidates through a heavy model inside a 2-second request. Hence Lesson 8's precomputation and Lesson 6's generateNewsfeed job.

It is where the reader-side hybrid pays. Lesson 8's active/lapsed split matters most here — ranking feeds for users who never open the app is the most expensive waste in the system.

Feature computation is a system of its own. "A list of friends a user frequently interacts with" and "topics on which a user spent more time" are aggregates over behavioural history. Those are precomputed offline into a feature store, not derived per request — and that is plausibly what Lesson 3's implausible 50 KB per user is actually measuring.

Ranking is what makes the feed non-chronological — with consequences the design does not name

A chronological timeline is stateless and self-explanatory: newest first. A ranked feed is neither, and the differences matter operationally.

No natural sort key. Lesson 6 established this — position 21 is wherever the model put it, which is why the feed must be frozen to be paginable.

Non-determinism. Rank the same candidates twice with an updated model and the order changes. So "refresh" genuinely means "a different feed," and the system must avoid re-showing what the user already saw — requiring seen-state per user that nothing in the schema stores.

Feedback loops. The model is trained on engagement with content the model chose to show. Content never surfaced generates no engagement data, so it is never learned to be good. That is a self-reinforcing loop, and mitigating it requires deliberately exploring — showing some content the model is unsure about.

The Google Maps chapter met the same structure with traffic routing: route everyone away from congestion and you stop observing whether it is still congested. Both are closed loops where the system's output becomes its own input, and both need damping.

Misinformation gets one bullet, and the design's own question is better than its answer

The service description says the algorithms "eliminate posts including misinformation or clickbait." One clause, no mechanism.

The design poses a sharper question elsewhere: "Newsfeeds often grapple with misinformation. What are two design-level interventions?"

Worth answering, because "the model filters it" is not one:

Reduce distribution rather than remove. Down-rank rather than delete. It avoids the free-speech confrontation of removal, and it works — reach is what matters, not existence.

Add friction. Prompt before resharing an article the user has not opened. A small delay measurably reduces the spread of low-quality content, and it is a product intervention with no model required.

Break the amplification loop. Cap how many hops a viral chain travels without a fresh human action, so resharing does not compound indefinitely.

Use the graph, not just the content. Misinformation spreads with a distinctive propagation pattern — sudden, clustered, from low-credibility sources. That is a graph signal available before any content model runs.

The last one is the most interesting because it is a systems answer to a content problem, and it fits this design: the graph database and the engagement counters already exist.

When a content-classification problem is hard, look for a propagation signal instead. It is often easier to detect how something is spreading than what it says.

The two-stage shape recurs in every recommendation system in this course. You cannot run an expensive model over every candidate, so a cheap stage narrows the field and the expensive one orders what is left.

Next: the assembled architecture.