System Design Interview
Personalized home feed inspired by Facebook's and Twitter's published designs: fan-out on write into precomputed feeds, hybrid pull for high-follower accounts, ranking at read time, plus search and trending. A teaching design, not either company's internal architecture.
See why computing every feed from scratch on each request can't scale.
What was missing: Nothing yet: one server and one database answer every feed request.
Why that's risky: Every refresh runs a join over hundreds of accounts' posts, and 200K refreshes per second crush one database.
What gets added: A server that builds each feed with a query over the posts of everyone the user follows, sorted by time.
Trade-offs: Always fresh and very simple, but the expensive work is repeated on every read.
Separate posts, the social graph and feeds, and cache hot data, while still building feeds on read.
What was missing: One server and one query did everything.
Why that's risky: Each feed read still fans out into reads of many accounts' posts, so the post cache takes several reads per refresh.
What gets added: A post service and sharded posts database, a social graph service and database, caches for posts and follow lists, and a feed service that merges followed accounts' recent posts on every request (pull).
Trade-offs: Pull keeps writes cheap and the feed always fresh, but read cost grows with how many accounts a user follows.
Do the work once when a post is published, so every feed read is a single lookup.
What was missing: Feeds were assembled on every read.
Why that's risky: An account with 50 million followers makes one post cost 50 million writes, and the feed is purely chronological.
What gets added: A fan-out queue and workers: when someone posts, the post id is pushed into each follower's precomputed feed in the feed cache. Reading a feed is now one cache read plus hydrating the newest posts.
Trade-offs: Writes multiply by follower count (about 200 on average here) to make reads cheap; most users read far more than they post.
Handle accounts with huge followings and order the feed by what each reader cares about.
What was missing: Huge accounts made fan-out explode, and the feed was ordered only by time.
Why that's risky: There's no way to search posts or see what's trending.
What gets added: Hybrid fan-out: normal accounts are pushed as before, but posts from accounts with millions of followers are pulled at read time and merged in. A ranking service scores the candidates on affinity, content type, freshness and engagement.
Trade-offs: A little read-time work for celebrity posts in exchange for capping fan-out cost; ranking adds latency but improves relevance.
Make posts searchable within seconds and surface what is rising.
What was missing: No search and no trending topics.
Why that's risky: Images and videos are still served by application servers, and nothing measures feed health.
What gets added: A post event stream feeding a search indexer and a trending counter over sliding windows, a search index over post text and hashtags, a trending cache and a search service.
Trade-offs: Search results lag posting by a few seconds; trends are approximate counts.
Serve images and videos from the edge and watch the feed's health.
What was missing: Media had nowhere to live outside application servers, and nothing measured fan-out lag or cache hit rates.
Why that's risky: Remaining risk is regional: feed caches must be rebuilt or failed over if a region is lost.
What gets added: Object storage for images and videos, a CDN in front of it, and monitoring of feed latency, fan-out lag and cache hit rates.
Trade-offs: CDN copies may stay briefly after a post is deleted until they're invalidated.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
