Social Media Feed System Design

The problem

Feeds look simple if you only stare at the interface.

The user opens the app and sees a list of posts. That is it.

But behind that list, the system has to handle:

• massive reads
• writes that may trigger work for millions of people
• constant updates
• regular accounts and giant accounts inside the same product

That is why feeds show up so often in interviews. The scenario feels familiar, but it forces you to show real architectural judgment.

Mental model

The cleanest way to think about a feed is to separate it into two paths:

1. the publishing path
2. the reading path

When someone publishes, the system must store the post and decide how that content reaches followers’ timelines.

When someone opens the app, the system must return a timeline that is fast enough, consistent enough, and cheap enough to run at scale.

That is where the two classic models come from:

• fanout on write: the system pushes the post into followers’ timelines when it is published
• fanout on read: the system builds the timeline when the user asks to read it

The first pays earlier. The second pays later.

Most mature answers are hybrid.

Breaking the problem down

First align on the kind of feed

Before drawing boxes, lock a few questions:

• is the feed chronological or ranked?
• does the first page need to be very fast?
• do most users follow a few people or many?
• are there giant accounts with tens of millions of followers?

Without that, the conversation turns into a pretty diagram with no criteria.

The write path: when someone publishes

In the publish flow, the system usually:

1. persists the post
2. emits an event or job
3. decides how to distribute the post

If the strategy is fanout on write, the system stores the post inside precomputed timelines for followers.

That usually makes reads very good, but it can explode cost when the author has a huge number of followers.

The read path: when someone opens the timeline

In the read flow, the system has to return a ready or almost-ready list.

It can:

• read a materialized timeline
• build the timeline on demand
• or combine a prebuilt base with some fragments assembled at read time

That decision defines a large part of the architecture cost.

The celebrity problem

If a user with few followers publishes, fanout on write is manageable.

If a huge account publishes, the same strategy can turn into a storm of writes, queue pressure, and cache invalidation at once.

That is why real systems often do something like this:

• regular users use fanout on write
• giant accounts use fanout on read or some special handling

This matters because follower distribution is not uniform.

A small number of accounts concentrate too much load for a naive design to stay cheap.

This is a strong interview point because it shows you are not assuming uniform distribution.

Cache, pagination, and ranking

Feeds almost always have cache somewhere, especially on the first page.

But cache alone does not solve the design. It only improves what was already chosen.

You still need to explain:

• what is being cached
• for how long
• how pagination works
• and how fresh the feed really needs to be

If the first page needs to feel instant, it deserves a different design from deeper pages.

If the feed is ranked, another cost appears: recomputing relevance. The explanation gets better when you show that ranking changes the read path and is not just a visual detail.

Simple example

A good interview answer could sound like this:

“I would separate the feed into two flows: publishing and reading. When a user publishes, the post is stored and an event is emitted. For regular users, I would do fanout on write and place the post into precomputed follower timelines. For very large accounts, I would avoid spreading to everyone during the write and would build part of the timeline on the read path instead. On reads, I would try to serve the first page from a ready timeline or from cache. That preserves a good experience for most cases without turning large accounts into permanent hotspots.”

That works because it:

• separates the flows
• shows the core trade-off
• handles the important exception
• avoids promising perfect consistency for free

Common mistakes

• Answering “I would use Redis” as if that were the design.
• Not separating publishing from reading.
• Treating regular users and celebrity accounts the same way.
• Ignoring pagination and the hot first page.
• Talking about ranking without acknowledging the extra cost.

How a senior thinks about it

People who have seen this kind of system in production usually reduce the conversation to two questions:

Where do I want to pay: on writes or on reads?

Who escapes the normal behavior and needs special treatment?

That clears a lot of confusion.

Instead of trying to sound sophisticated, the answer shows that the person can locate cost and protect the system from extreme cases.

What the interviewer wants to see

In this scenario, the interviewer wants to see whether you:

• separate write path and read path
• understand fanout as real cost, not as a buzzword
• recognize large-account hotspots
• use cache as support, not as an excuse
• explain a coherent design without trying to cover everything at once

A good feed does not come from a complicated diagram. It comes from deciding clearly where the system will pay for timeline speed.