Design a Social Feed

"Design a news feed" is the social-graph prompt Google asks most. It shows up under a dozen names: Twitter's timeline, an Instagram feed, a Facebook News Feed, a generic activity stream. They are all the same shape underneath. A user follows other accounts, and those accounts post. When our user opens the app, we have to assemble the posts from everyone they follow into one ranked list, fast. The interviewer usually lets you pick the product, then pushes on how you build that one screen.

Anchor on the asymmetry first, because the design turns on it. People read their feed far more than they post to it. A typical user posts maybe half a time a day and refreshes the app dozens of times, so reads outnumber writes by something like a hundred to one. That gap is the single most important fact in the room. It pushes you to spend real work when a post is created so that reading a feed is cheap. The three architectures below are just three different answers to where that work should happen.

The Google angle

Two things carry this round, and they happen to be the two Google's rubric weights hardest: data modeling and a clean read-versus-write split. A feed is almost nothing else. Where do you store a timeline, and do you build it when the post is written or when the feed is read? State the read/write ratio in the first two minutes and let every later choice fall out of it. And Google reasons at planet scale by reflex, so the celebrity problem (one account with a hundred million followers) isn't an edge case you bolt on at the end. It's the case they're waiting for you to reach on your own.