ML System Design · Module 40 of 47 · 13 concepts · about 14 min

Design: People You May Know

A complete design for recommending people to connect with on a social or professional network: link prediction on a graph, candidates from friends of friends and shared schools, workplaces and contacts, ranking for connections that are accepted and used, the scale problem of two-hop graph expansion, and the privacy care this feature demands.

At work: Asked as 'design people you may know' or 'design friend suggestions'. It is the standard graph ML question, and the feature that drives much of a network's growth.

Requirements

What it is

Circle (the made-up network from module 39) wants better connection suggestions. Clarify:

scale: about 300,000,000 users with an average of 200 connections;
surfaces: a suggestions page, a row in the feed, and suggestions right after sign-up;
goal: connections that are accepted and then used (people interact), not just requests sent;
latency: the suggestions page within a few hundred milliseconds; the list can be prepared ahead of time;
constraints: privacy (never reveal sensitive relationships), blocked users, people who opted out of being suggested.

Why it matters

Connections are the network's foundation: people with few connections leave.

But suggestions also carry risk: suggesting someone a person has deliberately avoided, or revealing who someone knows.

In the real world: Social networks have long reported that new users who reach a threshold number of connections early are far more likely to stay, which is why these suggestions get heavy investment.

Optimising requests sent. Annoying people into sending requests that are ignored damages trust on both sides.

Framing as link prediction

What it is

The network is a graph: people are nodes, connections are edges. 'People you may know' predicts missing or future edges:

target: probability that, if shown, the user sends a request and it is accepted (and ideally they then interact);
task: retrieve candidates likely to be linked, then rank them (pointwise, module 14);
offline metrics: AUC and recall at k on edges formed after a cut-off date (a time split on the graph);
online metrics: accepted connections per user; interactions on new connections; ignore and 'remove suggestion' rates.

Why it matters

Accepted-and-used connections are what grow the network.

A time split matters even more on a graph: using edges formed after the cut-off to compute features leaks the answer.

In the real world: Liben-Nowell and Kleinberg's classic paper framed this exactly as predicting which new edges will appear in a later snapshot of a network.

Evaluating by randomly hiding edges from today's graph. Features such as mutual friends are then computed with information from after those edges formed; split by edge creation time.

Candidates: friends of friends

What it is

Most new connections close a triangle: you meet a friend's friend. So the main candidate source is two hops away:

for each of the user's connections, gather their connections;
remove people already connected, blocked or opted out;
count mutual connections per candidate, and weight them: a mutual friend with few friends is a stronger hint than one with thousands (Adamic-Adar score: sum of 1 ÷ log(that friend's number of friends)).

Why it matters

Triangle closing explains a large share of new connections in real networks.

Weighting by the mutual friend's degree discounts very popular people, who connect everyone to everyone.

In the real world: Public descriptions of professional networks' connection suggestions name triangle closing over second-degree connections as a primary candidate source.

Visual example

Computed

You are connected to Asha, Bilal, Chen. Dev shares three mutual friends; Esha two; Chen's other friends one each.

Adamic-Adar = Σ over mutual friends of 1 ÷ ln(their number of friends)

candidate	mutual friends	count	Adamic-Adar
Dev	Asha, Bilal, Chen	3	2
Esha	Asha, Bilal	2	1.44
Farid	Chen	1	0.56
Gita	Chen	1	0.56
Hari	Chen	1	0.56
Isha	Chen	1	0.56

Chen has many friends, so a link through Chen counts for less than one through Asha or Bilal.

Ranking candidates by raw mutual count alone. Two people who share only celebrities or very large-network members as mutual connections may have nothing in common.

Other candidate sources

What it is

Friends of friends miss many real acquaintances. Add:

shared affiliations: same school, employer, city or group, especially at overlapping times;
contacts: people in the user's uploaded address book (only with consent), and people who have the user in theirs;
interactions: people the user has viewed, searched for, messaged in a group, or tagged;
graph embeddings: nearest neighbours in an embedding space learned from the graph (node2vec, or graph neural networks);
for new users, mostly contacts and affiliations, since they have no graph yet.

Why it matters

Each source finds connections the others cannot.

A new employee shares no friends with colleagues yet, but shares an employer.
Graph embeddings capture community structure beyond two hops.

In the real world: Social networks have faced public criticism for suggestions that revealed sensitive relationships, which led to stricter rules on which signals may be used.

Using sensitive signals as candidate sources. Suggesting someone because their phone was near yours, or because you both visited the same clinic, can reveal private facts.

The scale problem of two hops

What it is

Two-hop expansion explodes quickly:

with 200 friends each having 200 friends, a user has up to 40,000 friends-of-friends (fewer after overlaps);
highly connected users make it far larger;
so candidates are usually precomputed in batch (daily) with distributed graph processing, keeping the top few hundred per user;
with sampling (cap how many friends of each friend are considered) and incremental updates when new edges form.

Why it matters

Computing two-hop neighbourhoods for hundreds of millions of users on every page view is impossible; a daily batch makes it a lookup.

New connections change candidates immediately (a new friend brings new friends of friends), so incremental updates keep it fresh.

In the real world: LinkedIn has described graph-serving systems built to answer second-degree queries efficiently, alongside offline candidate generation for connection suggestions.

# Daily batch (for example in Spark): two-hop candidates with mutual counts, sampled for very large neighbourhoods.
friends = edges.groupBy("user").agg(sample_up_to("friend", 500).alias("friends"))
two_hop = (edges.alias("a").join(edges.alias("b"), col("a.friend") == col("b.user"))
           .where(col("a.user") != col("b.friend"))
           .groupBy(col("a.user").alias("user"), col("b.friend").alias("candidate"))
           .agg(count("*").alias("mutuals"), sum(1 / log(col("b.degree"))).alias("adamic_adar")))
candidates = two_hop.join(existing_edges, ["user", "candidate"], "left_anti")     # drop existing links

Computing friends of friends live from the graph database for each request. Popular users' neighbourhoods are enormous, and latency becomes unpredictable.

Ranking features

What it is

A model (boosted trees, or a graph neural network at larger scale) ranks a few hundred candidates using:

graph: mutual connections, Adamic-Adar, number of shared communities, distance in the graph, embedding similarity;
affiliation overlap: same school or employer, and whether the time periods overlapped;
interaction signals: profile views, searches, group co-membership;
candidate: how often they accept requests, how active they are, connection count;
reciprocity: whether the candidate is also likely to be suggested the user (mutual relevance).

Why it matters

Acceptance depends on the candidate, not only the user: someone who rarely accepts requests is a poor suggestion even if relevant.

Overlapping time at a school or employer is far stronger than merely sharing the name.

In the real world: Backstrom and Leskovec's 2011 work on Facebook data combined graph structure with node and edge features to predict new friendships, improving on structure alone.

Ignoring the receiving side. Suggesting a well-known person to thousands of strangers produces requests that are all ignored and burdens that person.

Practise it: Design a Recommendation System, Design a Personalized News Feed

Labels, training and feedback

What it is

Training data comes from past suggestions:

impressions of suggestions with position (module 5);
positive: request sent and accepted; strongest if followed by interaction;
negative: shown and ignored; explicitly removed ('not someone I know'); request sent but declined or left pending;
time split by when suggestions were shown, with features computed as of that time (module 11).

Why it matters

Accepted requests teach what leads to real connections; removals are valuable negatives.

Suggestions shape which connections form, a feedback loop (module 22), so some exploration of other candidate sources keeps learning broad.

In the real world: Connection-suggestion teams log every suggestion and its outcome specifically to train on accepted and removed suggestions.

Using today's mutual-friend counts as features for suggestions shown months ago. They include connections formed since, some because of the suggestion itself.

Practise it: Diagnose Model Drift, Design an ML Training Pipeline, Design Feature Monitoring, Design Model Monitoring, Diagnose Training-Serving Skew, Design a Personalized News Feed, Design a Search Ranking System, Design an Ad Ranking System, Design an ML Feature Store

Serving

What it is

A mostly precomputed system:

daily batch: candidate generation from all sources, feature computation, scoring, top few hundred stored per user;
near-line updates: when a user makes a new connection or joins a group, add the new friends of friends and re-score;
online: fetch the stored list, remove anyone connected, blocked or dismissed since, apply diversity (not all from one school), show;
new users: computed on sign-up from contacts and affiliations, since they have no batch results yet.

Why it matters

Most of the work is heavy graph processing best done in batch.

New-user suggestions must be immediate, because the first session decides whether they stay.

In the real world: Networks commonly show contact-based suggestions in the sign-up flow itself, then switch to graph-based suggestions once a few connections exist.

Visual example

Suggestions

Heavy graph work daily; light filtering live.

Producing a user's suggestions

Daily batch
candidate sources, in parallel
Friends of friendsTriangle closing
Shared affiliationsSchools, employers, groups
ContactsOnly with consent
FeaturesGraph, overlap, acceptance rate
ScoreAccepted, used connection
StoreTop few hundred per user
Live
ServeDrop blocked, connected, dismissed

Making new users wait for the next daily batch. Their first visit shows nothing useful, and many never return.

Practise it: Design Feature Monitoring, Diagnose Training-Serving Skew, Design a Model Serving Platform, Design an ML Feature Store

Privacy and safety

What it is

This feature needs more care than most:

sensitive signals (location traces, health-related groups, contacts of contacts without consent) must not drive suggestions;
blocks and opt-outs are absolute;
do not reveal why someone was suggested if the reason is private ('you were both near the same address');
watch for harmful suggestions: suggesting an abuser to a victim through shared contacts;
honour deletion: removed contacts and deleted accounts leave the graph and candidates promptly (module 25).

Why it matters

A single bad suggestion can expose a secret or put someone at risk.

These rules belong in hard filters and in the choice of allowed signals, reviewed by privacy specialists.

In the real world: Platforms limit which signals feed friend suggestions and offer controls to stop being suggested, following past public incidents.

Explaining suggestions with a detailed reason by default. 'Suggested because you have each other's numbers' can reveal that someone kept your number.

Evaluation

What it is

Offline and online, with the graph's growth in view:

offline: on a graph snapshot at a cut-off, predict edges formed in the following weeks; AUC, recall at k; slices for new users, small and large networks;
online: accepted connections and interactions on them; removal and ignore rates; requests received per person (to avoid flooding popular users);
long term: retention of new users; network health (are connections spreading across communities or only within one?).

Why it matters

New-user slices matter most, since that is where suggestions change outcomes.

Requests received per person guards against a system that pushes everyone towards the same few people.

In the real world: Growth teams typically judge connection suggestions by accepted connections that lead to interaction, and by new-user retention.

Visual example

Sources

Each finds a different kind of acquaintance.

Candidate sources compared

source	finds	weakness
Friends of friends	Friends' friends: most new links	Nothing for new users
Shared affiliation	Classmates, colleagues	Large schools and firms are noisy
Contacts (with consent)	Real-life acquaintances	Privacy-sensitive
Interactions	People you looked up or talked with	Can reveal private interest
Graph embeddings	Community members beyond two hops	Harder to explain

Optimising requests sent. A model that maximises sends spams popular users and lowers acceptance rates across the network.

Practise it: Design a Large-Scale Classification Platform, Design a Predictive Maintenance System, Design a Real-Time Anomaly Detection System, Design a Recommendation System, Diagnose Training-Serving Skew, Improve a Low-Recall Model, Design a Search Ranking System

Sources and further reading

What it is

Public work this design draws on:

Liben-Nowell and Kleinberg, 'The Link-Prediction Problem for Social Networks', 2007: link prediction and measures such as Adamic-Adar;
Backstrom and Leskovec, 'Supervised Random Walks: Predicting and Recommending Links in Social Networks', WSDM 2011: friend recommendation on Facebook data;
Grover and Leskovec, 'node2vec: Scalable Feature Learning for Networks', KDD 2016: graph embeddings;
Hamilton, Ying and Leskovec, 'Inductive Representation Learning on Large Graphs' (GraphSAGE), 2017: graph neural networks that handle new nodes;
LinkedIn Engineering blog posts on its graph-serving systems and connection recommendations.

Why it matters

Link prediction is a well-studied field; its classic measures and modern graph neural networks are both expected knowledge in this interview.

In the real world: Explaining Adamic-Adar in one sentence, and why it beats raw mutual counts, is a quick way to show depth on graph problems.

Interview questions: the people-you-may-know design

What it is

The questions interviewers ask about the people-you-may-know design, from the first screening call to the senior round. Cover the answer, say yours aloud, then compare.

Why it matters

Reading an idea and explaining it are different skills.

Each answer below is the two or three sentences an interviewer is listening for.
The reasoning behind each one is in the cards above. If an answer surprises you, go back to that card.

In the real world: PYMK is the most common graph question in ML interviews; triangle closing, scale and privacy are the three things to cover.

Q: How do you frame this problem?

Link prediction on the social graph: predict which edges will form, optimising for suggestions that are accepted and lead to interaction.

Q: Where do candidates come from?

Mainly friends of friends (triangle closing), plus shared schools and employers, consented contacts, interaction signals and graph-embedding neighbours; contacts and affiliations for new users.

Q: Why weight mutual friends by their degree?

A mutual friend with few connections is strong evidence; one with thousands connects everyone. Adamic-Adar sums 1 ÷ log(degree) over mutual friends.

Q: How do you handle the scale of two-hop expansion?

Precompute candidates daily with distributed graph processing, sample very large neighbourhoods, store the top few hundred per user, and update incrementally when new connections form.

Q: How do you evaluate it offline?

Snapshot the graph at a cut-off, compute features only from it, and predict edges that form afterwards; slice by new users.

Q: What privacy risks are there?

Revealing private relationships or sensitive signals through suggestions or their stated reasons; use only allowed signals, honour blocks and opt-outs, and avoid detailed reasons.

Ignoring privacy, or the burden on popular users.

Exercise: predict new connections

What it is

A short build that uses this module's ideas. Write it yourself before looking anything up; the checks at the end tell you whether it works.

Why it matters

An idea you have only read fades in a week.

Building it once, even in fifty lines, is what makes it yours.
Interviewers can tell the difference between someone who has read about a loop and someone who has debugged one.

In the real world: Link-prediction experiments like this are the foundation of growth and connection-recommendation work at social companies.

Your task. Predict future edges in a public social graph and compare simple graph measures with a learned model.

Steps

Use a public time-stamped graph (for example a Stanford SNAP dataset with edge timestamps, such as a collaboration or messaging network).
Split edges by time: build the graph from edges before a cut-off and use edges after it as the labels.
For each node, generate friends-of-friends candidates; compute mutual count and Adamic-Adar from the earlier graph only.
Measure recall at 10 for ranking by mutual count and by Adamic-Adar.
Train a boosted model on several graph features and compare.
Report results for nodes with fewer than five connections.

You are done when

Adamic-Adar beats raw mutual count, or you can explain why not on your graph.
The learned model beats both single measures.
No feature uses edges formed after the cut-off.

Stretch. Train node2vec embeddings on the earlier graph and add embedding similarity as a feature.