Design Twitter (or a similar social newsfeed system).

The complete answer guide: what this question really tests, two example strong answers in different angles, the common weak answer rewritten, and the trap most candidates fall into. This is a system design archetype question — see the broader pattern guide for the structural shape.

What this question is really testing

The interviewer isn't evaluating whether you can architect Twitter's actual infrastructure. They're testing whether you can navigate ambiguity, make pragmatic tradeoffs, and communicate technical decisions to stakeholders who might disagree with you. The real signal they're extracting is: can you drive a complex technical conversation without getting lost in irrelevant details, and do you understand that system design is fundamentally about choosing what not to build? They're worried you'll either bikeshed on trivial implementation details or hand-wave the hard parts with buzzwords like "we'll use Kafka for scale."

The binary read happening in their head is whether you think like a builder or a theorist. Builders ask clarifying questions that reveal business constraints, propose concrete schemas, and acknowledge that the first version will be imperfect. Theorists immediately jump to discussing consistent hashing and CAP theorem without understanding the actual requirements. The interviewer wants to see you make a decision with incomplete information, defend it with reasoning, and then adapt when they push back. They're not scoring your final architecture—they're scoring how you got there and whether you'd be tolerable to work with during a 3-hour design meeting.

Two strong answers, two angles

Angle A: Constraint-driven (start with the hard part)

"Before we dive in, I want to clarify the core constraint: are we optimizing for write throughput or read latency? If this is Twitter-scale with 500M daily users, the read-to-write ratio is probably 100:1, so I'd prioritize fast reads even if it means eventual consistency on the timeline. I'd start with a fan-out-on-write approach where we pre-compute timelines and store them in a cache like Redis—when you tweet, we push it to all your followers' cached timelines. This breaks down for celebrities with 50M followers, so we'd need a hybrid model where high-follower accounts use fan-out-on-read instead. The tradeoff is that Bieber's followers see slightly stale feeds, but 99% of users get sub-100ms timeline loads."

Angle B: User-journey-driven (start with the experience)

"Let me walk through the core user flow and identify the bottlenecks. When you open Twitter, you're loading a timeline of ~50 tweets from people you follow—let's say the average user follows 200 accounts. A naive approach queries all 200 users' recent tweets and merges them, but that's 200 database calls. Instead, I'd maintain a pre-computed timeline per user in a key-value store, updated asynchronously whenever someone they follow tweets. For posting, we write the tweet to a tweets table (partitioned by user ID), then trigger a background job to fan out to followers. The key design decision is whether to fan out synchronously or async—I'd choose async with a message queue because a 2-second delay in timeline updates is acceptable, but we can't make posting slow for users with millions of followers."

The common weak answer

"I'd use a microservices architecture with a tweet service, timeline service, and user service. We'd put a load balancer in front, use a CDN for images, and store data in a distributed database like Cassandra. For scale, we'd add caching and message queues."

This answer fails because it's a shopping list of technologies without any reasoning about tradeoffs or constraints. The interviewer learns nothing about your decision-making process—you've just named components any senior engineer would recognize. It signals you've memorized system design templates but can't think critically about when to apply them. You haven't asked a single clarifying question, proposed a data model, or acknowledged that different approaches have different costs.

Reframe: "Before choosing technologies, I need to understand our scale and consistency requirements. If we're at 100K DAU, I'd start with a monolith and Postgres. At Twitter's 500M DAU, I'd need to denormalize timelines into a cache. What scale are we designing for?"

The one trap most candidates fall into

The trap is starting with the database schema or API design instead of establishing the core technical challenge that makes this problem interesting. Most candidates immediately say "we need a users table, a tweets table, a follows table" and start drawing boxes. This signals you don't understand that the schema is trivial—the hard part is how you query it at scale. Twitter's defining challenge is the fan-out problem: when Kim Kardashian tweets to 70M followers, how do you update 70M timelines without melting your infrastructure?

Strong candidates identify this within the first two minutes: "The core challenge here is timeline generation at scale. Do we fan out on write—pre-compute every timeline when a tweet is posted—or fan out on read—compute timelines on-demand when users refresh? Both have breaking points." This immediately elevates the conversation to the actual engineering problem. Weak candidates spend 15 minutes designing a REST API and relational schema that any bootcamp grad could produce, then run out of time before discussing the interesting parts. The interviewer isn't wondering if you know what a foreign key is—they're wondering if you can identify that celebrity accounts need a completely different serving strategy than normal users, and that you'd need to instrument metrics to decide where that threshold is.

Common questions

Other system design questions