System Design Interview
Twitter/X architecture built progressively across 6 interview-scoped stages: tweet write path, follow graph, home-timeline fanout with hybrid celebrity handling, ranking/search (stretch goal), notifications/moderation, and monetization — kept deliberately lean (max 20 components) to match how a strong FAANG candidate would design and explain this system in 45 minutes.
Start with the core domain: create tweets, fetch tweet details, and model tweet lifecycle correctly.
What was missing: Nothing yet — this is the foundation. A naive first draft would put the User straight onto a single tweet server with no rate limiter and no object store, which falls over the moment media uploads or an abusive client shows up.
Why that's risky: A single un-sharded Tweet DB is a write bottleneck and a SPOF at this traffic level; acceptable for a Day-1 answer, not for the final one.
What gets added: A Load Balancer + a dedicated RateLimiter (not just an LB flag — interviewers expect to see it as its own decision point), a Tweet Service that owns the tweet CRUD path, a Tweet DB for durable storage, and a CDN + Blob Store pair so images/video never touch the app tier on a cache hit.
Trade-offs: No cache in front of the DB yet on purpose — stress testing this stage should show it as weak under a cache-outage scenario, which is exactly the lesson: you earn the cache in Stage 3, you don't start with one.
Add the social graph and the read models needed for user profile timelines and follow relationships.
What was missing: There was no notion of a social graph — Twitter is nothing without follows. Profile pages also had nowhere to live.
Why that's risky: Nothing computes a home timeline yet — today, 'following someone' has no visible effect on what a user sees. That gap is the entire motivation for Stage 3.
What gets added: A single User Service (profile + follow/unfollow, deliberately not split into 'ProfileAPI' and 'SocialAPI' — that's premature decomposition for this stage) backed by its own Follow DB, separate from Tweet DB so the graph can be scaled and partitioned independently of tweet storage.
Trade-offs: Follow DB is a graph-shaped read/write workload (fan-in/fan-out on celebrity accounts) that behaves very differently from Tweet DB's append-heavy workload — that's exactly why it's a separate store, not a table in the same DB.
Build the core read-heavy home timeline and handle the hardest product problem: celebrity fanout.
What was missing: The single hardest problem in this system: turning a tweet + a follow graph into a home timeline, at celebrity scale, without falling over.
Why that's risky: The event queue is now a single point of fanout delay under a write spike; if it backs up, timelines go stale for everyone — worth mentioning consumer-lag alerting even though it isn't drawn as a box.
What gets added: An Event Queue + Fanout Worker doing write-time fan-out into a Timeline Cache (Redis-style sorted set of tweet ids per follower) for normal accounts, a Tweet Cache in front of Tweet DB, and a Timeline Service that reads the cached timeline and, for celebrity/hot accounts, merges their tweets in at read time straight from Tweet Cache instead of fanning out to 50M followers on every tweet — this hybrid push/pull split lives entirely inside Timeline Service's own routing, not as a separate 'Hybrid' box, because in a real system it's a decision the timeline service makes per-author, not a standalone service.
Trade-offs: Fanout is asynchronous and eventually consistent — a new follower or a new tweet can take a moment to show up; that's the classic Twitter tradeoff and worth stating out loud in an interview.
Evolve from a recency feed into a ranked social platform with search and trending systems.
What was missing: A pure recency-ordered timeline and no way to find a tweet you didn't already have a link to — both are stretch-goal territory once the core read/write/fanout path is solid, which is why they land in Stage 4, not Stage 1.
Why that's risky: Search Index is a second source of truth for tweet text that must stay in sync with Tweet DB — an interview answer should mention 'near-real-time indexing pipeline' even though it's not drawn as a separate box here.
What gets added: A single Ranking Service (collapsed on purpose — a real candidate-retrieval + feature-store + scoring pipeline is 3-4 boxes in production, but for an interview answer one clearly-scoped 'scores and re-orders the candidate set, then caches the result' service is the right level of detail) that sits in front of Timeline Cache for cold/stale feeds, plus a Search Service + Search Index for keyword/hashtag lookup.
Trade-offs: Ranking adds latency and a new failure mode (a scoring bug or model rollout can silently make feeds worse, not just slower) — worth calling out as a monitoring gap even without drawing an observability stack.
Add the major asynchronous product workloads that make the platform feel alive and safe.
What was missing: No way to tell a user something happened, and no safety net against spam/abuse — both are asynchronous side-effects of a tweet being created, not synchronous parts of the write path.
Why that's risky: Moderation is async and post-hoc: a spam tweet is briefly live before being scored — acceptable tradeoff to state explicitly (latency budget for posting must never wait on an abuse model).
What gets added: A Notification Service and a Moderation Worker, both added as additional independent consumer groups on the SAME tweet-event stream that already feeds Fanout Worker — no new queue, no new publish path on Tweet Service, because one event correctly has three independent async subscribers. Tweet counters and reply/conversation threading are deliberately NOT new boxes: counts live on Tweet DB/Tweet Cache, and a reply is just a tweet with a parent_id handled by the existing Tweet Service/Tweet DB — giving them their own services would be over-decomposition for an interview-scoped design.
Trade-offs: Notification delivery coalesces bursts ("and 499 others liked your tweet") rather than sending 500 pushes — a concrete, interview-worthy detail that shows you've thought about the failure mode of naive fan-out notifications.
Finish with the platform view: monetization, analytics, model training, multi-region control, and safe operations.
What was missing: Monetization — the business model that actually pays for everything above it.
Why that's risky: Ad selection quality/relevance is a whole separate ML system in production; here it's correctly scoped as 'out of bounds' for this design — said out loud, not hidden.
What gets added: One Ad Service that slots a sponsored tweet into the feed within a strict render-time budget; nothing else. This is intentionally the smallest possible Stage 6: multi-region active-active deployment, an analytics/experimentation data warehouse, ML training pipelines, an observability/incident-response stack, automated backups, and config/service-discovery infrastructure are all real production concerns a strong candidate should MENTION VERBALLY at this point in an interview — but drawing them as boxes would turn a 45-minute interview-level design into an infrastructure diagram. State them as 'here's what I'd add given more time', don't draw them.
Trade-offs: Ad Service has a hard timeout with a drop-the-slot fallback — monetization must never be allowed to slow down or destabilize the core product; a clean, quotable interview line.
Use a hybrid approach. Precompute timelines for normal users where follower counts are manageable; switch celebrities and extreme hot accounts to fanout-on-read or partial materialization to avoid explosive write amplification.
Use tombstones in the tweet store and publish delete events to all downstream consumers. Timeline caches, search indexes, conversation graphs, and analytics readers must interpret deletes idempotently.
Separate candidate generation from ranking. Use a candidate timeline store, cache hydrated tweets, maintain an online feature store, and degrade to recency or lightweight ranking when feature systems are slow.
Write interaction events to a stream, aggregate asynchronously, and store eventually consistent counters separately from tweet objects. Keep UI tolerant to lagging counts and dedupe interaction events by user/tweet/action.
Profile timelines are author-centric and easy to partition by author/time, while home timelines are user-specific and require graph joins, fanout, and ranking. Keeping them separate avoids mixing two very different read patterns.
Compute trends from the engagement stream asynchronously using windowed aggregations by region/topic. Serve trends from precomputed stores and let search or trends APIs degrade independently from core timeline reads.
Keep ad selection separate from organic feed computation. Inject sponsored candidates during ranking with pacing, campaign targeting, policy rules, and strict latency budgets; fall back gracefully if ad systems are unavailable.
Keep the tweet write path minimal and durable, then fan out events asynchronously. Downstream systems should consume independently with retries and DLQs; the platform should degrade by disabling enrichments rather than blocking core posting.
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:
