Why Great System Design Always Starts With Better Questions

The most common mistake in system design interviews is jumping to solutions too quickly. Presented with "Design Twitter," most engineers immediately start drawing boxes: load balancers, web servers, databases, caches. But the best designs begin with questions, not answers.

Key sources: "System Design Interview" by Alex Xu, "The Design of Everyday Things" by Don Norman.

The Problem with Solution-First Thinking

When you start by drawing architecture, you make implicit assumptions:

• "Users upload photos, so I need a CDN and an object store." (What if the product is text-only?)
• "Traffic is high, so I need a load balancer and auto-scaling." (What if the product has low traffic?)
• "We need a NoSQL database for scalability." (What if the data has complex relationships?)

These assumptions may be wrong. A CDN is useless if users upload private documents. Auto-scaling adds unnecessary complexity if traffic is predictable.

The fix: ask questions first.

The Five Essential Questions

Before drawing a single box, answer these five questions:

1. What Are We Building?

This seems obvious, but requirements are often ambiguous.

• "Design a chat system" — is it one-on-one or group? Do messages persist? Is it encrypted? Are there attachments?
• "Design a URL shortener" — do we need analytics? Custom aliases? Expiration? User accounts?
• "Design a news feed" — is it algorithmic or chronological? Does it include ads? Are there different content types?

Bad question to ask: "What features should we build?" (Too open-ended)

Good question: "What is the most important feature — the one that makes this product useful?" (Focuses on the core)

2. What Is the Scale?

Scale determines architecture. The answer changes everything:

| Dimension | Small Scale (10K users) | Large Scale (10M users) | |-----------|------------------------|------------------------| | Web servers | 1-2 servers | Auto-scaling groups | | Database | Single instance | Replicated cluster | | Storage | Local disk | S3/GCS | | Caching | Not needed | Redis/Memcached | | CDN | Not needed | Required for static assets |

Bad question: "How many users?" (Too vague)

Good question: "How many daily active users and what is the peak requests per second?" (Specific and actionable)

3. What Are the Consistency Requirements?

Different features have different consistency needs:

• User profile updates: Strong consistency (don't show a stale profile picture)
• News feed posts: Eventual consistency (a slight delay in seeing a post is acceptable)
• Payment transactions: Strong consistency (must be accurate)
• Like counts: Eventual consistency (a few seconds delay is fine)

Mixing consistency requirements in the same system is common. A photo-sharing app might use strong consistency for album permissions and eventual consistency for view counts.

4. What Are the Latency Requirements?

Latency requirements drive technology choices:

• Real-time chat: <100 ms delivery. WebSocket or long polling required.
• Video streaming: <5 seconds start time. CDN and adaptive bitrate required.
• Analytics dashboard: <5 seconds load time. Caching and pre-aggregation acceptable.
• Email delivery: Minutes to hours. A queue-based system works fine.

Knowing latency requirements prevents over-engineering. Chat needs push. Email does not.

5. What Can We Simplify?

The best designs are simple. Ask:

• "What can we leave out of version 1?"
• "What existing service can we use instead of building our own?"
• "Which features are rarely used and can be deprioritized?"

This is where experienced engineers distinguish themselves. They know that a simple design that works is better than a complex design that is "more scalable."

From Questions to Design

Once you have answers, the design almost writes itself:

text Requirements: URL shortener, 100M URLs/month, read-heavy (90% reads) → Read-heavy means caching is essential → 100M URLs/month = ~4M writes per day = ~46 writes/second → Reads at 10x writes = ~460 reads/second → This fits on a single PostgreSQL instance with Redis caching → Simple design: one web server, one database, one cache

text Requirements: Chat app, 1B messages/day, low latency, group chats → Message throughput is high → partition by conversation ID → Low latency → WebSocket preferred → Offline delivery → store messages, deliver on reconnect → Group chats → fan-out on read for large groups → Multiple components: WebSocket servers, message queues, database

Notice how the design follows from the requirements, not from a template.

The Design Process

1. Clarify: Ask the five essential questions
2. Estimate: Calculate the numbers (storage, bandwidth, requests per second)
3. Define API: What endpoints or interfaces does the system expose?
4. Design data model: What entities exist? How are they stored and accessed?
5. Architecture: What components are needed? How do they connect?
6. Deep dive: Pick the most interesting part and go into detail
7. Trade-offs: Acknowledge what you are sacrificing with your choices

Key Takeaways

1. The best system designs start with questions, not solutions.
2. Five essential questions: what, what scale, what consistency, what latency, what can we simplify?
3. Requirements drive architecture. Do not apply patterns before understanding the problem.
4. Simple designs that meet requirements are better than complex designs that are "more scalable."
5. Estimating numbers prevents both over-engineering and under-engineering.

Design principle: A question asked is a mistake avoided. Spend the first 20% of your design time clarifying requirements and challenging assumptions.