Social Network System Design Interview Walkthrough

When an interviewer says "design a social network", they are not asking for a finished diagram. They are listening for four things: how you scope an open problem, whether your high-level architecture hangs together, how deep you can go on one or two components, and whether you can name and defend trade-offs out loud. The candidates who freeze usually jump straight to tables and columns. The ones who pass open with a plan: scope the core features, sketch the read and write paths, then go deep on the feed and storage. This social network system design interview walkthrough is built as a spoken sequence, so you always know what to say next.

Four things are being scored, and none of them is a perfect diagram:

Scoping. Can you turn a vague prompt into a bounded problem in a few minutes?
A coherent high-level architecture. Do the boxes and arrows tell one story, with each component earning its place?
Depth on one or two components. Can you go two or three levels down on the feed or the storage layer when asked?
Explicit trade-offs. Can you say what you gave up and why, before you are pushed?

"Social network" is deliberately vague. Clarifying it is part of the test, not a delay. An interviewer wants to see whether you narrow a problem the way you would on a real team, where nobody hands you a spec.

Open with one sentence that sets the shape of the next 35 minutes:

"I'll scope the core features, sketch the read and write paths, then go deep on the feed and storage."

That sentence buys you structure. The interviewer now knows where you are going and can redirect early if they want a different emphasis.

Spend the first five minutes on requirements, out loud, in three steps. Then run them as one script.

Step 1: Sort requirements into three columns

Say them as you write them:

Functional: post, follow, feed, like and comment.
Non-functional: read-heavy, low-latency feed reads, eventual consistency acceptable for feeds.
Out of scope: ads, search, messaging.

Naming what you are leaving out is as valuable as naming what you include. It shows the interviewer you know the problem is bigger than the session and that you are choosing.

Step 2: Ask two clarifying questions

Keep them short and answerable:

"Is the feed chronological or ranked? And roughly how many followers does a typical user have — is there a celebrity case?"

Those two questions change the architecture. A ranked feed needs a scoring step; a celebrity case forces you to handle accounts with millions of followers. Ask them early, then move on with a stated assumption if the interviewer waves you forward.

Step 3: Do a back-of-envelope estimate in the open

State your read:write ratio as an assumption, not a fact. Work it with round numbers and label them: "Say a million users, each posting twice a day — that's about two million writes a day. If each user loads their feed ten times a day and follows a few hundred people, that's ten million reads a day, so reads outnumber writes several times over. I'm optimising for feed read latency." Then say what changes if you are wrong: "If writes dominated, I'd revisit the fan-out strategy." The interviewer is watching how you reason under uncertainty, not whether your number is right.

The whole five minutes, as one script

Here is the same ground covered in one breath, so you can rehearse it as a block:

"I'll scope this as post, follow, feed, like and comment, with read-heavy, low-latency feed reads and eventual consistency acceptable for feeds. Out of scope: ads, search and messaging. Two questions — is the feed chronological or ranked, and is there a celebrity case with very high follower counts? I'll assume chronological and a mix of normal and high-follower accounts. For capacity, I'll assume reads outnumber writes several times over, so I'm optimising for feed read latency; if that's wrong, I'd revisit fan-out."

Sketching the architecture: which boxes go on the whiteboard first?

Draw the write path and the read path as two separate stories. Narrate each one as you draw it.

Write path: client → API gateway → post service → post store → fan-out worker.

Read path: client → feed service → feed cache → post store.

The order to draw components:

Clients — web and mobile.
Gateway or load balancer — one entry point, auth and routing.
Services — post service, feed service, follow service.
Caches — feed cache in front of the feed service.
Primary stores — post store and follow graph.
Async workers — fan-out and media processing.

Say why each exists in a clause, not a paragraph. "The feed cache exists because feed reads dominate and we want them to avoid the post store." Then add one line the interviewer rarely hears and always appreciates:

"I'm deliberately not drawing the ranking service or the media pipeline yet — I'll add them if we have time."

That tells them your omissions are choices, not gaps.

The feed decision: fan-out on write, fan-out on read, or both?

This is usually the decision interviewers probe hardest. Lay out the three options before you pick one.

Strategy	Writes	Reads	Best when
Fan-out on write (precomputed feed)	One write per follower	Read a list	Most users have modest follower counts
Fan-out on read (merge at read time)	One write	Merge many sources	Writes are frequent or followers are many
Hybrid	Mixed	Fast for most, merge for some	A mix of normal and high-follower accounts

The hybrid answer is the one to reach for: precompute feeds for normal users, merge at read time for accounts with very high follower counts. Treat the threshold as a tunable, not a magic number — say you would set it from measured fan-out cost.

Then defend it in one sentence:

"I'm optimising for feed read latency because reads dominate; the cost is write amplification, which I accept because posting is not latency-critical."

That sentence names the choice, the reason and the cost. Practise saying it until it is automatic. For a closer look at the same decision in a narrower case, see the Notification System System Design Interview: A Narrated Walkthrough.

Storage and data model: what do you store, and where?

Separate the entities and say which store fits each:

Users: a relational or document store; small, read-heavy, needs consistency.
Follows (the graph): an adjacency list, often in a wide-column store; each row is a user and their followees.
Posts: a wide-column or document store keyed by author and time; append-heavy.
Feed (materialised timeline): a per-user list, usually in a cache or wide-column store, rebuilt by fan-out.

Name the hot-partition risk out loud: an account with millions of followers creates a partition that fan-out workers hammer. That is exactly why the hybrid feed exists. If you want to go deeper on key choice, the consistency models system design interview guide shows how to pick and defend a consistency choice.

Handle media separately: images and video go to object storage behind a CDN, with only metadata in the primary store. The CDNs system design interview guide covers the edge-caching reasoning.

Where do the real system design trade-offs show up?

Use this sentence pattern for every trade-off: "I chose X over Y because Z; the cost is W, which I would revisit if…"

Decision	Chosen over	Because	Cost
Hybrid fan-out	Pure write or pure read	Balances read latency and write cost	More moving parts to operate
Eventual consistency for feeds	Strong consistency	Feed staleness of seconds is acceptable	A new post may not appear instantly
Caching feeds	Always reading the post store	Feed reads dominate	Cache invalidation on delete and edit
Wide-column for posts	Relational	Append-heavy, huge volume	Weaker ad-hoc query support

Here is the difference between naming a trade-off and defending it.

Weak: "I'd use a cache for the feed because it's faster."

Stronger: "I chose a feed cache over reading the post store on every request because feed reads dominate and latency matters most there. The cost is staleness and invalidation work when a post is deleted, which I'd revisit if the product needed strong consistency on the feed."

The weak version states a preference. The strong version states the alternative, the reason and the cost, which is what the interviewer is scoring. For the consistency side of this, see the consistency models system design interview guide.

How do you handle the follow-up curveballs?

Expect three common follow-ups. The technique is to extend, not repeat: acknowledge the new constraint, name what changes, state the new cost.

"What breaks at 10x traffic?" Say what saturates first — usually fan-out workers and the feed cache — then what you would shard or add.
"How do you handle a deleted post in precomputed feeds?" Either mark it deleted and filter at read time, or fan out a delete; each has a cost you can name.
"What if the feed must be strongly consistent?" Say what you would give up: precomputation becomes harder, read latency rises, and you lean more on read-time merge.

For the general technique, the guide on how to respond to follow-up questions in an interview covers extending an answer without restarting it.

Drawing the schema before agreeing on requirements. Fix: run a 60-second scoping script first, every time.
Presenting the feed as one obvious solution. Fix: show the three options, then defend your pick with its cost.
Going silent while thinking. Fix: narrate the decision, not the diagram — say what you are weighing as you weigh it.

Each fix works because it gives the interviewer something to follow. Silence and premature detail both hide your reasoning, and your reasoning is what is being assessed.

If you freeze or give a weak answer mid-interview, name it, restate the assumption you were working from, and continue. That works because the interviewer is scoring how you recover, not whether every sentence lands perfectly.

A 30-minute practice routine you can run before the interview

Run this drill out loud, timed, and record it:

5 minutes: scope the problem aloud — requirements, clarifying questions, read:write assumption.
10 minutes: whiteboard narration — write path, read path, component order.
10 minutes: trade-off defence — the four-row table, spoken in full sentences.
5 minutes: follow-ups — the three curveballs above.

Review the recording for three things: where you went silent, where you named a trade-off without its cost, and where you drew before you scoped. Then run the same case twice — once for structure, once for defending under interruption. To compare cases, the notification system system design interview walkthrough uses the same narrated format. Repeating the social network system design interview drill this way builds the spoken habits the real session needs.

Before you walk in

The social network system design interview rewards a spoken plan more than a perfect diagram. Scope for five minutes, narrate the read and write paths, and defend at least three trade-offs with their costs before you are asked. Pick one case, set a 30-minute timer, record yourself, and review where your reasoning went quiet.

Frequently asked questions

Should I assume the feed is chronological or ranked, and does it change the architecture?

Ask, then state your assumption. Chronological keeps the design simpler: fan-out writes an ordered list and reads return it. Ranked adds a scoring step, usually at read time or in a periodic rebuild, so the feed becomes a candidate set plus a ranking pass. Either way, the fan-out choice stays the central decision.

How much detail on the follow graph does the interviewer expect at mid-level versus senior?

At mid-level, naming it as an adjacency list with a sensible store is usually enough. At senior level, expect to discuss hot partitions for high-follower accounts, how you would shard the graph, and how fan-out workers read it efficiently. Offer that depth yourself rather than waiting to be asked.

Do I need to design the chat or messaging feature too, or is that a separate interview?

Treat messaging as out of scope and say so in your first five minutes. It has different requirements — delivery guarantees, presence, ordering — and folding it in usually costs you depth on the feed. If the interviewer insists, acknowledge the new constraint and name what changes.

How do I estimate capacity when I don't know the real user numbers?

Pick round numbers you can multiply in your head, then sanity-check reads against writes so the ratio you state matches the story you are telling. Say each figure aloud as an assumption, not a fact, and name what you would change if the real numbers differed. The method matters more than the figures.

What if the interviewer disagrees with my fan-out choice — how do I recover without backtracking everything?

Acknowledge the concern, restate the trade-off and adjust one variable. For example: "If writes dominate, I'd move high-follower accounts to read-time merge." That shows you can hold a position and revise it under new constraints, which is stronger than abandoning the whole design.

Rehearse the walkthrough out loud and review how you sounded.