System Design Interview
Social network inspired by Facebook's published designs: a TAO-style object and association graph in sharded MySQL behind tiered caches, privacy checks on every read, feeds assembled at read time from in-memory activity leaves and ranked, notifications, social search and integrity classifiers. A teaching design.
See why rendering every page with SQL against one database collapses.
What was missing: Nothing yet.
Why that's risky: A single page needs dozens of queries (the person, their friends, each post, its likes), and 200K page views per second crush one database.
What gets added: One server rendering profiles, posts and the feed with SQL against one database.
Trade-offs: Simple, but the social graph is read far more than it's written.
Model the social graph explicitly and serve almost all reads from memory.
What was missing: Pages ran many SQL queries each, all on one database.
Why that's risky: Any server that fetches an object could show it to anyone: audiences and blocks aren't checked consistently.
What gets added: A TAO-style data model of objects (people, posts, comments) and associations (friend, authored, liked) in sharded MySQL, behind a read-through graph cache with follower tiers for reads and leader tiers that write through and keep caches consistent; photos in object storage behind a CDN.
Trade-offs: Caches are eventually consistent across regions; a person always reads their own writes.
Make sure nobody ever sees something its audience excludes.
What was missing: Audience rules were checked inconsistently, page by page.
Why that's risky: The feed is still assembled by querying every friend's posts.
What gets added: A privacy checker that every object passes through before it's shown, applying its audience (public, friends, custom lists) and the viewer's blocks.
Trade-offs: Every object costs a privacy check; checks read audience lists from the graph cache to stay fast.
Build each feed fresh, in under a second, from recent activity of everyone followed.
What was missing: Feeds queried every friend's posts from the graph.
Why that's risky: People aren't notified of comments and likes, and there's no search.
What gets added: An activity stream and leaf indexers that keep each person's recent actions in memory on leaf servers, and a feed aggregator that queries the leaves for everyone the viewer follows, ranks the candidates and checks their privacy at read time.
Trade-offs: Pull at read time does more work per feed view than precomputed feeds, but handles accounts with huge followings and privacy changes instantly.
Tell people about interactions and let them find people and posts.
What was missing: No notifications and no search.
Why that's risky: Harmful content and fake accounts aren't caught, and nothing limits posting rates.
What gets added: A notification worker for comments, likes, tags and friend requests, and a social search index (fed from the activity stream) whose results favour the searcher's connections.
Trade-offs: Search results lag new posts by seconds.
Catch harmful content, slow abuse, and watch the platform.
What was missing: No integrity checks, no abuse limits, no monitoring.
Why that's risky: Remaining risk is regional: graph caches and shards must fail over between data centres.
What gets added: An integrity classifier on the activity stream that removes clear violations and queues borderline ones for human review, rate limits on posting and friending, and monitoring of page and feed latency and cache hit rates.
Trade-offs: Classification happens just after posting, so a violation can be visible for seconds.
Require a client-supplied idempotency key for post creation. Persist the key with the final post ID and return the stored result on retries. Use a queue/outbox to publish to feed fan-out and notifications asynchronously.
Write fan-out materializes follower timelines asynchronously for fast reads at scale; read fan-out composes on read, reducing write load but increasing read latency. Many systems mix both: materialize partial feeds for hot users and compose on read for long tails.
Index user handles, names, hashtag tokens, and post text into a Search Index asynchronously via a queue. Query the index for autocomplete, trending, and discovery; do not scan the OLTP databases.
Apply token bucket or sliding window rate limits at the edge per IP and per user. Backed by a fast cache store. Monitor for anomalies and add circuit breakers on hot endpoints.
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:
