Design LinkedIn's People You May Know

Design a scalable, privacy-aware People You May Know recommendation system.

Introduction

30 Second Summary

People You May Know can feel effortless when one familiar professional appears at the right moment. Finding that person becomes difficult when millions of connections must be checked before the page loads.

In this project, you will design a People You May Know recommendation system in Excalidraw. Your design evolves a small social graph into a scalable candidate pipeline.

What You'll Build

Your finished diagram shows a second-degree candidate reaching the viewer through a read path that remains bounded as the graph grows.

By the end of this project, you'll have:

A visible member graph that lets you trace a second-degree recommendation through one mutual connection.
A bounded candidate pipeline that routes reads across graph partitions. Caching reduces repeated work. Deduplication keeps each suggestion unique.
A three-minute interview narrative that explains why filtering happens before ranking. It traces an asynchronous graph update. It demonstrates a smaller fallback result when a graph replica is unavailable.
Secret Mission: Add an authoritative block check that removes a newly blocked member from stale cached recommendations.

Are there any prerequisites?

You need a Mac with browser access to Excalidraw. Basic familiarity with system design helps you focus on the architecture decisions.

No installation or account is required.

Before We Start

A clear user problem gives every component in your system design a reason to exist. Your design helps a LinkedIn member discover relevant people through second-degree connections because a mutual connection provides social context and likely relevance.

Set Up Excalidraw and Sketch the Graph

Your LinkedIn People You May Know brief now explains why a mutual connection matters. A visible graph gives that idea a concrete shape before infrastructure enters the design.

Excalidraw gives you a shared canvas for every later architecture decision.

This step leaves you with a reusable legend. It also gives you a saved three-member chain.

In this step, get ready to:

Open the free Excalidraw editor without an account.
Create a legend for the diagram's visual language.
Save a labeled three-member graph as an editable local scene.

Create the Excalidraw legend

A legend gives every shape one consistent meaning. This keeps the larger architecture readable when more components appear.

Visit excalidraw.com in your browser.
Continue into the free editor without creating an account.

You'll see an empty canvas with drawing tools around its edges.

Press R to select the rectangle tool.
Draw a small rectangle near the upper-left corner of the canvas.

The first legend shape is now visible on the canvas.

Press Enter while the rectangle is selected.
Type Member node inside the rectangle.

The first symbol now represents one person in the network.

Press R to reselect the rectangle tool.
Draw a wider rectangle beneath the member node symbol.

The wider shape gives services more visual weight than individual members.

Press Enter while the wider rectangle is selected.
Type Service box inside the rectangle.

Your legend can now distinguish a member from a service.

Press R to reselect the rectangle tool.
Draw another wide rectangle beneath the service box.

This third shape becomes the symbol for stored data.

Press Enter while the new rectangle is selected.
Type Data store inside the rectangle.

The three labeled shapes establish the main object types for your architecture.

Select the arrow tool from the left toolbar.
Draw a horizontal arrow beside the member node symbol.

This arrow gives your legend a reusable connection symbol.

Press Enter while the arrow is selected.
Type Connection edge as its label.

The labeled arrow now represents a relationship between members.

Select the arrow tool from the left toolbar again.
Draw a second horizontal arrow beneath the connection edge.

This final legend symbol represents movement through the future request path.

Press Enter while the second arrow is selected.
Type 1 Request as its label.

Your legend now contains a member node, a connection edge, a service box, a data store, plus a numbered request arrow.

Why start with a legend?

The legend fixes one visual meaning for each symbol. That consistency makes a crowded system design easier to follow.

Numbered arrows also give you a clear order for explaining request flows during an interview.

Sketch the two-hop member graph

A social graph represents each member as a node. An edge records one connection between two members.

The degree label counts how many edges separate another member from the viewer. Your sample graph makes that distance visible.

Move to a clear area on the right side of the canvas.
Press R to select the rectangle tool.

The clear space keeps the sample graph separate from its legend.

Draw one rectangle for the first member.
Repeat the rectangle pattern twice to create a horizontal row of three members.

You should now see three separate member shapes arranged from left to right.

Label the left rectangle Viewer using Enter.
Label the middle rectangle Maya using Enter.

The first two members now identify the person requesting suggestions plus their direct connection.

Label the right rectangle Jordan using Enter.
Select the arrow tool from the left toolbar.

All three member nodes are now ready to be connected.

Draw one connection edge from Viewer to Maya.
Draw another connection edge from Maya to Jordan.

The three members now form a chain with two connection edges.

Place the label first-degree above the edge between Viewer and Maya.
Place the label second-degree above the edge between Maya and Jordan.

The hop labels make the recommendation relationship visible at a glance.

How does the two-hop path work?

Viewer connects directly to Maya. That makes Maya a first-degree connection.

Jordan sits one more edge away through Maya. That mutual path makes Jordan a second-degree candidate for Viewer.

Preserve the editable scene

Excalidraw stores the browser scene in LocalStorage by default. An editable local export gives you a second copy outside browser storage.

Leave the Excalidraw browser tab open to retain the browser scene.
Open Excalidraw's main menu from the upper-left corner.

Your browser copy remains available while you create the local backup.

Choose Excalidraw's JSON save-to-file export.

Your browser downloads an editable scene file to your Mac. That gives the diagram a local backup you can reopen later.

Confirm the editable scene file appears in your browser's downloads list.

Take a moment to predict the member Viewer reaches in exactly two hops.

Return to the Excalidraw browser tab from earlier.
Trace the first connection from Viewer to Maya.
Continue the trace from Maya to Jordan.

You'll arrive at Jordan after two edges. The path passes through Maya as the mutual connection.

Point to the five entries in your legend.
Confirm the graph shows three labeled members plus two connection edges.

You should be able to distinguish every legend symbol. You should also see the first-degree label on the first hop plus the second-degree label on the second hop.

That's your visual foundation in place. Next, you'll turn this member chain into a complete recommendation read path.

Trace a Working Two-Hop Recommendation

Your three-member graph now makes one mutual connection visible. The next goal is to turn that example into a complete People You May Know read path in Excalidraw.

Starting with the smallest complete two-hop path makes the recommendation behavior visible before scale adds more machinery. This working baseline gives you something concrete to test later.

In this step, get ready to:

Define the rules for a valid People You May Know recommendation.
Draw a numbered read path from the viewer to the graph data.
Prove the path returns the second-degree member as a ranked candidate.

Define the recommendation rules

A requirements panel defines which suggestions count as valid before the architecture becomes more complex. Each rule gives a later component a clear responsibility.

Return to the Excalidraw scene from earlier.
Press R to select the rectangle tool.
Draw a wide rectangle to the right of your sample graph.
Press Enter inside the rectangle to add Requirements.
Add Return ranked second-degree candidates.
Add Exclude the viewer and existing connections.
Add Respect visibility rules.
Add Tolerate slightly stale non-safety-critical recommendations.

Your panel now separates useful recommendations from invalid ones. These rules become the checks for the read path you draw next.

Why Allow Slight Staleness?

A recommendation can lag behind a recent non-safety-critical update. Visibility rules still remain mandatory.

Draw the working read path

A read path shows how one request moves through the system. The Recommendation Service coordinates each graph lookup.

The service also owns the deduplication step. That step prevents repeated or excluded members from reaching the response.

Place a copy of the member-node shape from your legend in an open area on the left.
Change the copied label to Viewer.
Place a copy of the service-box shape from your legend in the center.
Change the copied label to Recommendation Service.
Place a copy of the data-store shape from your legend on the right.
Change the copied label to Graph Store.

Good progress. The three core boundaries of your read path are now visible.

Add a Viewer-to-Recommendation Service arrow labeled 1 request.
Add a Recommendation Service-to-Graph Store arrow labeled 2 first-degree lookup.
Add a second Recommendation Service-to-Graph Store arrow labeled 3 neighbor lookup.
Add a loop arrow beside Recommendation Service labeled 4 deduplication.
Add a Recommendation Service-to-Viewer arrow labeled 5 response.

How Does the Read Path Work?

The 1 request arrow submits the viewer's recommendation request.
The 2 first-degree lookup arrow retrieves the viewer's direct connections.
The 3 neighbor lookup arrow expands those connections by one more hop.
The 4 deduplication arrow removes repeated candidates. It also applies the viewer and existing-connection exclusions.
The 5 response arrow returns the remaining ranked candidates.

Trace the recommendation result

Candidate generation turns graph neighbors into possible recommendations. A result card proves the system returns the right member with useful social context.

Record the label on the final member in your three-member chain as: your second-degree member label.
Record the label on the middle member as: your mutual connection label.
Draw a result card below Recommendation Service.
Add People You May Know at the top of the card.
Add Rank 1 below the card title.
Add Candidate: followed by your second-degree member label.
Add Mutual connection: followed by your mutual connection label.

The result card now turns the traversal into an observable answer. It shows who the system recommends and why that person is relevant.

Before you trace the full path, do you expect either the viewer or the first-degree member to survive the exclusion rules?

Trace 1 request from Viewer to Recommendation Service.
Match 2 first-degree lookup to the middle member in your sample graph.
Match 3 neighbor lookup to the final member in your sample graph.
Use 4 deduplication to confirm the final member passes every exclusion rule.
Follow 5 response to the result card.

You should finish at a result card containing your second-degree member label. The viewer and first-degree member are excluded.

The card names your mutual connection label as the shared connection. That is your first complete People You May Know recommendation.

Save the updated scene locally with Excalidraw's JSON 'save to file' export.

Does the Trace Produce the Wrong Member?

Check that the first sample member connects only to the middle member.
Check that the middle member connects to the second-degree candidate.
Check that the result card names the final member instead of the viewer or mutual connection.

Help me debug my two-hop recommendation trace.

Your two-hop recommendation now works from request to result. Next, a high-degree member will expose where the naive traversal breaks.

Break the Naive Traversal

Your Excalidraw diagram now turns a mutual connection into a visible People You May Know result. That working read path gives you a baseline to stress.

A high-degree member makes the two-hop social graph traversal expand into unbounded work. You will expose that bottleneck before comparing the costs of two extreme computation strategies.

In this step, get ready to:

Expand the mutual connection into a super-connector with a large candidate cloud.
Annotate the naive traversal's scaling failures.
Compare fully precomputed traversal with fully on-demand traversal.

Create the high-degree super-connector

A high-degree member is a graph node with many connection edges. It turns one neighbor lookup into a wide candidate expansion.

Select the mutual member in the middle of the three-member chain.
Edit the selected member label to Super-connector using Enter.

The middle member now represents someone with a much larger network than the original example.

Draw at least eight member nodes to the right of Super-connector using the legend as your visual guide.
Arrange the new member nodes into a loose cloud.

You can now see a much larger second-degree neighborhood beside the original chain.

Connect Super-connector to every new member node with an outgoing edge.
Label the cluster Candidate cloud.

Good progress. Your once-small second hop now branches into a candidate cloud that can overwhelm the original read path.

Expose the read-time failures

Fan-out measures how widely one operation spreads into downstream work. A high-degree member can trigger many neighbor reads from one recommendation request.

Before you trace the request, do you expect the original second-degree lookup to stay small around Super-connector?

Start at Viewer on the numbered request path.
Trace 1 request through Recommendation Service to Graph Store.
Follow 2 first-degree lookup into Super-connector.
Follow 3 neighbor lookup across every outgoing edge into the candidate cloud.
Compare the number of candidate reads with the original three-member chain.

The lookup now expands across the entire candidate cloud. This shortfall is intentional.

Choose a red colour swatch from the canvas toolbar before adding the failure annotations.
Add Excessive fan-out beside the outgoing edges from Super-connector.

The red label now marks where one lookup explodes into many operations.

Add Repeated neighbor reads beside 3 neighbor lookup.
Add Duplicate candidates beside 4 deduplication.

The read path now shows how repeated traversal creates work that the deduplication stage must clean up.

Add Cross-partition fan-out across the path between Graph Store and the candidate cloud.
Add Oversized candidate set beside the candidate cloud.

The diagram now connects broad traversal with storage pressure and response-size growth.

Add Hot storage partition beside Graph Store.

You have exposed the full chain of failure. A single high-degree member now creates fan-out across the read path and concentrates demand on one storage partition.

Compare the two extremes

Precomputation pays read costs earlier by storing derived candidate sets. Every connection change can then trigger write amplification across many stored sets.

On-demand traversal calculates fresh candidates at request time. User-facing latency becomes unpredictable.

Draw a note panel beside the red failure annotations.
Add the heading Traversal trade-off.

The new panel gives the two extreme strategies a dedicated comparison space.

Add Fully precompute second-degree sets to the left side of the note.
Add Reduces read work below the precomputed option.

The first option now shows why storing every second-degree set can make reads simpler.

Add Raises storage and write amplification below the read-work benefit.
Add Fully on-demand traversal to the right side of the note.

The comparison now shows the cost of precomputing every derived set beside the alternative strategy.

Add Preserves freshness below the on-demand option.
Add Creates unpredictable latency below the freshness benefit.

That comparison is now visible. Full precomputation shifts pressure to storage and writes. Full on-demand traversal shifts pressure to request latency.

Before you trace the overloaded request one last time, which failure do you expect to appear first?

Start the final trace at Viewer.
Follow the numbered request through Recommendation Service and Graph Store.
Continue through Super-connector into the full candidate cloud.

What should I see?

The branch from Super-connector is marked Excessive fan-out.

The neighbor lookup is marked Repeated neighbor reads and Cross-partition fan-out.

The merge stage is marked Duplicate candidates. The candidate cloud is marked Oversized candidate set.

The Graph Store is marked Hot storage partition. The note compares full precomputation with full on-demand traversal.

That's the bottleneck exposed. Your diagram now proves why the working naive traversal cannot scale around a high-degree member.

The failure is now impossible to miss. Next, you will replace uncontrolled traversal with routed partitions, bounded candidate generation, caching, and deduplication.

Build a Scalable Candidate Pipeline

Your Excalidraw canvas now shows exactly where the naive two-hop traversal breaks around a super-connector. The red annotations turn an abstract scale problem into a visible bottleneck.

This step replaces uncontrolled fan-out with routed graph partitions. Bounded expansion keeps the amount of read-time work predictable.

Selective caching reuses recent candidate results. The hybrid design avoids storing every second-degree set forever.

In this step, get ready to:

Route first-degree adjacency lists through a shard router.
Build bounded candidate generation with deduplication.
Add a Candidate Cache for brief reuse.

Route adjacency lists to graph partitions

An adjacency list records a member's first-degree neighbors. Placing each list in one logical partition gives the router a predictable ownership rule.

Switch back to the Excalidraw canvas from earlier.
Add a service box labeled Shard Router beside the naive Graph Store.

You should now see a new routing layer beside the original failure path. The naive diagram remains visible for comparison.

Add a data store box labeled Graph Partitions to the right of the Shard Router.
Add this note inside Graph Partitions: Each member's first-degree adjacency list resides in one logical partition.

Your scalable branch now shows how graph ownership is divided. Each member's immediate neighborhood has one logical home.

Draw a request arrow from the existing Recommendation Service to the Shard Router.
Draw a request arrow from the Shard Router to Graph Partitions.

The new branch now reaches partitioned graph data without replacing your original Graph Store path.

Add this note beneath the Shard Router: Router locates required partitions.

Before you trace this branch, where should a member lookup go before it reaches graph data?

Trace the branch from the Recommendation Service through the Shard Router to Graph Partitions.

You should reach the router before any partition. This confirms that partition locations stay behind one routing boundary.

What changed with partitioning?

Each logical partition owns the first-degree adjacency list for a member. This creates a clear rule for placing graph data.

The Shard Router maps lookups to the required partitions. The design no longer assumes that one Graph Store serves every read.

Build bounded candidate generation

The Candidate Generator controls how much of the two-hop neighborhood becomes active work. Its cap prevents a super-connector from dictating the full response size.

Add a service box labeled Candidate Generator to the right of Graph Partitions.
Draw a request arrow from Graph Partitions to the Candidate Generator.

Your routed graph reads now feed a dedicated candidate-processing stage. This separates graph retrieval from candidate control.

Add Expand a bounded set of first-degree neighbors as the first line inside the Candidate Generator.
Add Merge candidates as the second line.

The first half of the box now defines a controlled expansion followed by one merged candidate stream.

Add Remove duplicates as the third line.
Add Cap candidate set as the fourth line.

The Candidate Generator now has an explicit stopping boundary. Duplicate paths through mutual connections collapse before the bounded result continues.

Label the arrow entering the Candidate Generator with Adjacency lists for bounded expansion.

Before you trace the super-connector again, do you expect every outgoing candidate to pass the cap?

Trace the high-degree branch from Graph Partitions through the Candidate Generator.

The trace now stops expansion at the candidate cap. The full candidate cloud remains in the failure diagram as evidence of the work your new boundary avoids.

Why cap before downstream work?

A high-degree member can expose a huge two-hop neighborhood. Bounded expansion gives each request a controlled amount of graph work.

Merging removes repeated paths to the same person. The cap keeps the remaining candidate set small enough for later stages.

Document the hybrid cache strategy

The Candidate Cache stores selected results briefly so repeated requests can reuse recent work. The Deduplicator creates a clear final merge boundary before delivery.

Add a data store box labeled Candidate Cache after the Candidate Generator.
Add a service box labeled Deduplicator after the Candidate Cache.

The right side of your scalable branch now has a temporary reuse point followed by a final duplicate-removal boundary.

Draw a request arrow from the Candidate Generator to the Candidate Cache.
Draw a request arrow from the Candidate Cache to the Deduplicator.

Candidate results now pass through brief storage before their final deduplication check.

Draw a response arrow from the Deduplicator back to the Recommendation Service.
Draw a final response arrow from the Recommendation Service to the existing Viewer.

Your scalable branch now forms a complete request-response loop. The original result card can still show the candidate returned to the viewer.

Add one note with these five lines: Hybrid design. Materialize first-degree adjacency. Generate second-degree candidates at read time. Briefly cache selected results. Precompute only reusable ranking features.
Number the scalable request arrows from the Viewer through the pipeline before numbering the response arrows back to the Viewer.

The completed branch now shows where graph data lives. It also shows where candidate work becomes bounded.

Why use this hybrid?

First-degree adjacency is a reusable view. Materializing it gives the router a stable source.

Every second-degree set can grow rapidly. Precomputing all of them increases storage plus write amplification.

Bounded read-time generation controls expansion. Brief caching reuses selected results.

Precomputing only reusable ranking features keeps heavier work selective.

Update your editable local copy using the same JSON save-to-file export from earlier.

Your local JSON copy now includes the partitioned graph path plus the bounded candidate pipeline.

Before you trace the final branch, do you expect the full two-hop neighborhood or a bounded candidate set to reach the Deduplicator?

Trace the numbered request from the Viewer through the Recommendation Service, Shard Router, Graph Partitions, Candidate Generator, Candidate Cache, and Deduplicator.

You should see the request reach the Candidate Generator after the partition reads. Only the capped candidate set continues through the cache to the final deduplication boundary.

Strong work. Your scalable branch now turns the super-connector from uncontrolled fan-out into bounded candidate work.

Your candidate pipeline now controls graph expansion without losing the original recommendation behavior. Next, you'll add the checks plus failure behavior that make those recommendations safe and dependable.

Add Ranking, Freshness, and Resilience

Your bounded candidate pipeline now protects the LinkedIn read path from uncontrolled fan-out. The next goal is to turn its candidate set into ranked suggestions that remain useful as the graph changes.

Candidate generation alone cannot produce safe, relevant, or dependable recommendations. You will extend the Excalidraw design with the read safeguards and write propagation needed to close those gaps.

In this step, get ready to:

Build the filtered ranking stage.
Map new connections through the asynchronous update path.
Complete the resilient architecture with an interview narration panel.

Add filtering and ranking

The bounded candidate set can still contain a private member. It also lacks an order for delivery.

Policy filtering removes ineligible candidates before ranking spends work on relevance. The Feature Store supplies reusable signals while keeping real LinkedIn production weights outside the design.

Switch back to the scalable request flow on your existing canvas.
Extend the flow after the existing Deduplicator with a service box labeled Visibility Filter.
Connect Visibility Filter to a new service box labeled Ranker.
Place a data-store shape labeled Feature Store below Ranker.
Draw an arrow from Feature Store to Ranker with the label Ranking features.

Why Filter Before Ranking?

Filtering applies hard visibility rules before soft relevance scores. A high-scoring private candidate still stays out of the response.

LinkedIn's published FollowFeed design applies privacy filtering before relevance algorithms. Your diagram uses that ordering as a transferable teaching pattern.

Add Mutual connections as the first signal inside Feature Store.
Add Shared company as the second signal inside Feature Store.
Add Shared school as the third signal inside Feature Store.
Add Shared skills as the fourth signal inside Feature Store.
Add the caption Teaching examples only. Production weights are unspecified. beside the signal list.
Mark one candidate entering Visibility Filter with the label 1. Private candidate.
Place a stop marker on that candidate's line at Visibility Filter.

Before you trace this scenario, make a mental prediction about whether the private candidate reaches the Ranker.

Trace scenario 1 from the candidate set through Visibility Filter.

You'll see the private candidate stop before the Ranker. The remaining eligible candidates continue to scoring.

Use the JSON save-to-file export from earlier to replace your local editable scene.

Draw asynchronous connection updates

A new connection changes the source graph before every cached or derived view catches up. An event-driven write path makes that delay explicit on the canvas.

Add a service box labeled Connection Service beside the graph update area.
Draw an arrow from Connection Service to a new box labeled Event Stream.
Branch an arrow from Event Stream to Graph Partitions with the label Update adjacency list.
Branch another arrow from Event Stream to Candidate Cache with the label Invalidate selected entries.
Branch a final arrow from Event Stream to Feature Store with the label Refresh reusable features.
Add the note Derived views are eventually consistent across the update branches.

What Does Eventual Consistency Mean?

With eventual consistency, the graph update can arrive before the cache invalidation or feature refresh. The derived views converge after their event handlers finish.

This keeps connection writes independent from every downstream update. Brief recommendation staleness becomes an explicit trade-off.

Place a marker labeled 2. New connection beside Connection Service.

Before you trace scenario 2, predict whether every derived view updates at the same instant.

Trace scenario 2 from Connection Service through every Event Stream branch.

You'll see one event branch toward each downstream view. Those separate branches show why the derived views can briefly disagree.

Use the JSON save-to-file export from earlier to update your local editable scene.

Finish the resilient design

An unavailable graph replica can shrink the candidate pool without taking down the recommendation. This behavior is called graceful degradation.

How Partial Results Stay Dependable

Replication gives graph reads alternate copies of adjacency data.

Timeouts keep stalled reads from holding the whole request.

Monitoring makes reduced coverage visible to operators.

Add a grouped set of data-store shapes labeled Graph Replicas beside Graph Partitions.
Connect Shard Router to Graph Replicas.
Mark one graph replica as unavailable with a red cross.
Label the graph read boundary with Timeout.
Place a service box labeled Monitoring beside the read path.
Draw dashed reporting lines from the read-path components to Monitoring.
Add the label Partial result: return available candidates beside Recommendation Service.
Place a marker labeled 3. One graph replica unavailable beside the crossed replica.

Before you trace scenario 3, predict whether one unavailable replica stops the entire response.

Trace scenario 3 from Shard Router through the available graph data to the response.

What Should You See?

The timeout cuts off the unavailable replica.
The available graph data still reaches Candidate Generator.
Recommendation Service returns a smaller candidate set.
Monitoring records the reduced graph coverage.

The final panel turns the architecture into a concise interview story. Each section gives you a clear transition to the next design decision.

Draw a panel titled Three-minute interview narration beside the completed architecture.
Divide the panel into four numbered sections.
Add Requirements: Return ranked second-degree candidates. Apply connection and visibility exclusions. to section 1.
Add Naive bottleneck: A super-connector causes excessive fan-out, repeated reads, duplicate candidates, and a hot partition. to section 2.
Add Scalable design: Route adjacency reads to partitions. Bound candidate expansion. Cache selected results. Filter before ranking. to section 3.
Add Trade-offs: Brief staleness lowers read work. Partial fallback protects availability with a smaller result. to section 4.
Deliver the four-part narration aloud in three minutes.
Use the JSON save-to-file export from earlier to replace your local editable scene.

Before the final walkthrough, make a mental prediction about whether the design still returns suggestions when one graph replica is unavailable.

Trace scenario 1 from the private candidate to Visibility Filter.
Trace scenario 2 from Connection Service through the asynchronous update branches.
Trace scenario 3 from the unavailable replica to the smaller fallback response.
Use the four narration sections to explain the complete design aloud.

Your Final Check

Scenario 1 removes the private candidate before ranking.
Scenario 2 propagates the new connection asynchronously to graph data, cached candidates, and reusable features.
Scenario 3 returns fewer candidates instead of failing the whole request.
The narration panel covers requirements, the naive bottleneck, the scalable design, and its trade-offs.

That's the full main design complete. Your canvas now explains how ranked recommendations stay private, fresh enough, and available during a partial graph failure.

Secret mission

Make Blocking Safe Under Stale Caches

A block can be committed while the Candidate Cache still contains the blocked member. Extend your design with an authoritative final check that protects the Viewer during this stale-cache race.

Clean Up Your Resources

Your browser-based Excalidraw design has no ongoing costs. Choose whether to keep the scene available, save it for later, or delete it entirely.

Resources you used:

Complete Excalidraw scene stored in browser storage.
Editable JSON scene saved locally on your Mac.

Keep everything running

No action needed. Choose this if you are still refining your interview-ready social graph design.

Leave the Excalidraw scene in browser storage.
Keep the editable JSON scene on your Mac as a local backup.

Pause - I'll come back to this later

Browser storage can be cleared. Your saved editable JSON scene protects the work while you step away.

Switch back to the Excalidraw tab from earlier.
Confirm the canvas still contains the complete People You May Know design.
Use your Mac's file browser to confirm the editable JSON scene is still available.
Close the Excalidraw browser tab after confirming the local copy.

Delete - I don't want to use this again

Remove the browser scene and local editable export if you do not plan to return to this design.

Switch back to the Excalidraw tab from earlier.
Select every object on the Excalidraw canvas.
Delete the selected objects.
Confirm the Excalidraw canvas is blank.
Close the Excalidraw browser tab.
Use your Mac's file browser to locate the editable JSON scene.
Move the editable JSON scene to Trash.
Open Trash to confirm the JSON scene is there.

Nice Work!

You made it! Your Excalidraw canvas now presents an interview-ready People You May Know social graph design.

You've learned how to:

Trace a visible two-hop traversal from the Viewer to a second-degree candidate. Explain each recommendation through its mutual connection.
Diagnose the high-degree-member bottleneck in a naive read path. Your annotations isolate excessive fan-out. Another mark exposes repeated work. The candidate cloud shows the oversized result. The hot storage partition completes the failure story.
Build a scalable read path with routed Graph Partitions plus bounded candidate generation. Caching limits repeated computation. Deduplication removes overlapping candidates. Privacy filtering protects policy boundaries before ranking. Eventual consistency keeps derived views fresh. Replication supports graph availability. Graceful degradation returns partial results during failures. Your four-part interview narrative explains the requirements. It identifies the naive bottleneck. It presents the scalable design. It closes with the trade-offs.
Secret Mission: Added an authoritative final block check after cached candidate retrieval. It removes a newly blocked member before the response reaches the Viewer. Uncertain block status now fails closed.

Ready to quiz yourself?