- Introduction
- Clarifying the Requirements
- Describing the Architecture
- Analyzing Trade-offs
- Discussing Scaling
- Choosing the Database
- Key Expression Comparison Table
- A Mock Interview Dialogue
- Common Mistakes and How to Fix Them
- Interview Preparation Checklist
- References
- Conclusion
Introduction
A system design interview measures something fundamentally different from a coding interview. You are not writing a correct answer in code; the core of it is designing a complex system while conveying your own thinking clearly in English.
Plenty of non-native developers have the technical ability but cannot explain their design intent and trade-offs effectively in English, and come away from the interview disappointed. The interviewer is not simply hunting for "the right answer" — they are watching how the candidate thinks and communicates.
This article organizes the English you need at each stage of a system design interview, along with conversation patterns you can use in the room, the mistakes people make most, and a preparation checklist.
Clarifying the Requirements
The first stage of a system design interview is requirements clarification. Diving straight into the design is the most common mistake, and the interviewer wants to see how a candidate turns an ambiguous problem into a concrete one.
Basic Clarification Expressions
[Opening the interview - clarifying requirements]
"Before I dive into the design, let me clarify a few requirements."
(The line that buys you clarification time before you design anything.)
"What's the expected scale of this system? Are we talking about
thousands or millions of users?"
(Scale is the first number that changes every decision after it.)
"Should we focus on read-heavy or write-heavy workloads?"
(Read-heavy or write-heavy decides the storage design.)
"What are the most critical non-functional requirements?
Latency, availability, or consistency?"
(Asks which non-functional requirement wins when they conflict.)
Bounding the Scope
[Setting the scope]
"Given the time constraint, I'd like to focus on the core
functionality first and then discuss extensions if time permits."
(Names the time constraint, then commits to a core-first order.)
"Let me scope this down. For the initial design, I'll focus on
the messaging system and defer the notification system."
(Narrows to one subsystem and defers the rest out loud.)
"Are there any specific features you'd like me to prioritize?"
(Hands the priority choice back to the interviewer.)
Confirming the Numbers
[Checking the numbers]
"What's the expected QPS (queries per second) for this service?"
(QPS is the single most useful number to get early.)
"How much data are we expecting to store? What's the retention period?"
(Volume plus retention gives you the storage estimate.)
"What's the acceptable latency for the end user?
Sub-100 milliseconds or is higher latency acceptable?"
(Turns "it should be fast" into a millisecond budget.)
Describing the Architecture
Once the requirements are settled, you move on to describing the whole architecture. At this stage you have to convey the big picture of the system and the role of each component clearly.
Describing the Whole Architecture
[Architecture overview]
"Let me start with a high-level architecture overview."
(Announces that you are starting from the top level.)
"At a high level, this system consists of three main components:
an API gateway, a processing layer, and a data storage layer."
("At a high level, this system consists of" plus a component list.)
"The API gateway routes all incoming requests and applies
rate limiting and authentication."
(One sentence per component: what it routes and what it enforces.)
Describing How the Components Interact
[Component interaction]
"When a user sends a message, the request first hits
the load balancer, which distributes it to one of our
application servers."
(Traces the request hop by hop, in order.)
"The application server validates the request, writes to
the message queue for asynchronous processing, and returns
a confirmation to the client."
(Three verbs in sequence describe a multi-step handler cleanly.)
"This microservice is stateless, which makes scaling
much easier because we can simply add more instances
behind the load balancer."
("Because it's stateless" is the reason that makes scaling trivial.)
Describing the Data Flow
[Data flow]
"Let me walk you through the data flow for a typical request."
("Walk you through the data flow" sets up the narration.)
"The data flows from the client through the CDN for static
assets, then hits our API servers for dynamic content."
(Separates the static path from the dynamic path.)
"We use an event-driven architecture here, where services
communicate through a message broker rather than direct
API calls."
(Names the architectural style, then how the services actually talk.)
Analyzing Trade-offs
Trade-off analysis is one of the most important parts of a system design interview. The interviewer is checking whether you recognize the upsides and downsides of your design, and can explain why one approach beats another in this particular context.
The Basic Trade-off Expression
[Explaining a trade-off]
"The trade-off here is between consistency and availability.
Given that this is a social media feed, I'd prioritize
availability over strict consistency."
(Names both sides, then which one this product picks.)
"On one hand, using a relational database gives us strong
consistency and ACID transactions. On the other hand,
a NoSQL database would give us better horizontal scalability."
("On one hand... on the other hand..." is the balanced comparison.)
"There's a tension between latency and data freshness.
Caching improves latency but introduces the risk of
serving stale data."
("There's a tension between X and Y" states the conflict directly.)
Making a Choice With the Reasons Attached
[Justifying the choice]
"I'm going with eventual consistency here because, for this
use case, users can tolerate a few seconds of delay before
seeing the latest data."
(Ties the choice to what this specific use case can tolerate.)
"I'd choose a message queue over direct synchronous calls
because it decouples the services and improves fault tolerance.
If the downstream service goes down, messages are preserved
in the queue."
(Two reasons, plus the concrete failure it survives.)
"The downside of this approach is increased complexity in
managing distributed transactions, but I believe the benefits
of independent deployability outweigh this cost."
(Names the downside yourself, then says why the upside still wins.)
Comparing Alternatives
[Comparing alternatives]
"I considered two approaches: a push model and a pull model.
The push model has lower latency for notifications, but
the pull model is simpler to implement and scales better
for users who follow many accounts."
(Names both options, then the strength of each.)
"Another option would be to use a hybrid approach,
where we use push for active users and pull for
less active users."
(Offers the hybrid, which is often the strongest answer.)
Discussing Scaling
The scaling discussion is where you explain how the system responds as it grows. You need to explain in clear English the difference between horizontal and vertical scaling, how you identify bottlenecks, and your performance optimization strategy.
Horizontal vs. Vertical Scaling
[Scaling strategy]
"We could horizontally scale this service by adding more
instances behind the load balancer. Since the service is
stateless, horizontal scaling is straightforward."
(States the mechanism, and the property that makes it easy.)
"For the database layer, vertical scaling might be
sufficient initially, but as we grow beyond a certain
threshold, we'll need to implement sharding."
(Concedes vertical scaling short-term, commits to sharding later.)
"Horizontal scaling provides better fault tolerance
since there's no single point of failure, but it
introduces complexity in data consistency."
(Gives both the benefit and the cost of scaling out.)
Identifying Bottlenecks
[Identifying the bottleneck]
"The database is likely to become a bottleneck as the
number of concurrent users increases. To address this,
we can introduce read replicas and a caching layer."
(Predicts the bottleneck, then names the two standard fixes.)
"I'd identify the potential bottlenecks as follows:
first, the write path to the database; second, the
computation-heavy recommendation engine; and third,
the network bandwidth for media delivery."
(Numbering the bottlenecks makes the analysis easy to follow.)
"Caching the most common queries reduced average latency
by 40 percent in similar systems I've worked with."
(Backs the claim with a number from real experience.)
Performance Optimization
[Performance optimization]
"We can use a CDN to serve static content closer to
the user, reducing latency significantly."
(Names the mechanism — closer to the user — behind the CDN win.)
"To handle traffic spikes, I'd implement auto-scaling
policies based on CPU utilization and request count."
(Ties autoscaling to the two signals that trigger it.)
"We can implement circuit breakers to prevent cascading
failures when a downstream service is unresponsive."
(Circuit breakers are the standard answer to cascading failure.)
Choosing the Database
Database choice is a topic interviewers dig into often. You need to be able to explain why you picked a particular database, and how that decision affects the rest of the system.
Reasons Behind Each Database Type
[Choosing the database]
"For the user profile data, I'd use a relational database
like PostgreSQL because we need strong consistency,
complex queries with joins, and ACID transactions."
(Three concrete requirements justify the relational choice.)
"For the activity feed, I'd choose a NoSQL database like
Cassandra because it's optimized for write-heavy workloads
and provides excellent horizontal scalability."
(Justifies NoSQL by workload profile, not by fashion.)
"For the caching layer, Redis would be a good fit because
it supports various data structures, provides sub-millisecond
latency, and supports pub/sub for real-time features."
(Three properties of Redis, each tied to a real need.)
Explaining the Schema Design
[Schema design]
"For this table, I'd denormalize the data to avoid
expensive join operations at read time."
(Says the denormalization is deliberate, and names what it avoids.)
"I'd add an index on the user_id and created_at columns
to optimize the query pattern for fetching recent posts
by a specific user."
(States the index and the query pattern it exists to serve.)
"The partition key would be the user_id, which ensures
even distribution of data across shards and efficient
lookups for user-specific data."
(Names the partition key and the two properties it buys.)
Key Expression Comparison Table
A table of the expressions that come up most in system design interviews. Drill it before the interview and the English comes out naturally.
| Concept | English expression | Example |
|---|---|---|
| Clarify what is being asked for | clarify the requirements | "Let me clarify the requirements before we begin." |
| The top-level design | high-level design | "Here's the high-level design of the system." |
| The point that limits throughput | bottleneck | "The database could become a bottleneck." |
| Adding more machines | horizontal scaling (scale out) | "We can horizontally scale the web tier." |
| Making one machine bigger | vertical scaling (scale up) | "Vertical scaling has a physical limit." |
| Two goods you cannot have at once | trade-off | "The trade-off is between latency and consistency." |
| One component whose failure takes everything down | single point of failure (SPOF) | "We need to eliminate any single point of failure." |
| Surviving a component failure | fault tolerance | "This design provides better fault tolerance." |
| Replicas converge over time | eventual consistency | "Eventual consistency is acceptable here." |
| Every read sees the latest write | strong consistency | "Banking requires strong consistency." |
| Time to respond | latency | "The p99 latency should be under 200ms." |
| Volume handled per unit time | throughput | "We need to handle 10K requests per second." |
| Clearing stale entries from the cache | cache invalidation | "Cache invalidation is one of the hardest problems." |
| Spreading traffic across instances | load balancing | "A load balancer distributes traffic evenly." |
| Splitting data across nodes | data partitioning / sharding | "We'll shard the database by user_id." |
| Duplicating data to speed up reads | denormalization | "Denormalization helps reduce read latency." |
| A read-only copy of the primary | read replica | "Read replicas offload traffic from the primary." |
| Capping how often a caller may call | rate limiting | "Rate limiting prevents abuse of the API." |
| A buffer between producer and consumer | message queue | "A message queue decouples producers and consumers." |
| A switch that stops calling a failing service | circuit breaker | "Circuit breakers prevent cascading failures." |
A Mock Interview Dialogue
A mock exchange showing the flow of a real system design interview, on the topic of designing a URL shortening service.
[Interviewer] "Design a URL shortening service like bit.ly."
[Candidate] "Sure, I'd love to work through this.
Before I start, let me clarify a few requirements.
First, what's the expected scale?
How many URLs are we shortening per day?"
[Interviewer] "Let's say 100 million new URLs per day,
and a 10:1 read-to-write ratio."
[Candidate] "Got it. So that's roughly 100 million writes per day
and about 1 billion reads per day.
Let me do a quick back-of-the-envelope calculation.
That's about 1,200 writes per second and 12,000 reads
per second on average, with potential peaks of maybe
3 to 5 times that.
For the high-level design, I'd propose the following
components:
1. An API gateway for rate limiting and authentication
2. A URL shortening service that generates unique short codes
3. A redirection service that handles the lookups
4. A database to store the URL mappings
5. A caching layer for frequently accessed URLs
For generating the short URL, I have a few options.
I could use a hash function like MD5 or SHA-256 and
take the first 7 characters, or I could use a
base-62 encoding with an auto-incrementing counter.
I'd go with the base-62 approach using a distributed
ID generator because it guarantees uniqueness without
collision handling, which simplifies the system.
The trade-off is that base-62 with a counter is
slightly less random than hashing, which means
sequential URLs are somewhat predictable. But for
a URL shortener, this isn't a security concern."
[Interviewer] "How would you handle the database layer?"
[Candidate] "For the database, I'd use a NoSQL store like
DynamoDB or Cassandra. Here's my reasoning:
The data model is simple - it's essentially a
key-value lookup from short URL to long URL.
We don't need complex joins or transactions.
The access pattern is primarily point reads by key.
NoSQL databases excel at horizontal scaling for
this type of workload.
To improve read performance, I'd add a Redis cache
in front of the database. Given the 10:1 read-to-write
ratio, caching would significantly reduce database load.
For the cache eviction policy, I'd use LRU
(Least Recently Used) since popular URLs tend to
be accessed repeatedly within short time windows."
[Interviewer] "What about availability and reliability?"
[Candidate] "Great question. For high availability, I'd
implement the following:
First, the application servers are stateless,
so we can run multiple instances behind a load
balancer. If one instance fails, traffic is
automatically rerouted.
Second, for the database, I'd use multi-region
replication to handle regional failures.
Third, the cache layer would use a cluster setup
with automatic failover.
The main trade-off for multi-region replication is
between consistency and latency. I'd opt for
eventual consistency with a replication lag of
a few seconds, which is acceptable for a URL
shortener since a newly created URL doesn't need
to be globally available instantly."
Common Mistakes and How to Fix Them
Mistake 1: Jumping Straight to the Solution
[BAD]
"Okay, so I'll use a microservices architecture
with Kafka and Redis and..."
[GOOD]
"Before I jump into the solution, let me make sure
I understand the requirements correctly.
What's the expected scale, and what are the most
critical quality attributes for this system?"
The interviewer wants to see you make an ambiguous problem concrete by clarifying it. Reeling off a tech stack right away is the most common mistake there is.
Mistake 2: Naming a Technology With No Reason
[BAD]
"I'd use Kafka here."
[GOOD]
"I'd use a message queue here - something like Kafka
or RabbitMQ. The key reason is that we need to decouple
the write path from the processing pipeline to handle
traffic spikes gracefully."
Whenever you name a specific technology, give the reason for the choice alongside it. If you cannot answer the interviewer's "why?", you are better off not naming it at all.
Mistake 3: Never Mentioning a Trade-off
[BAD]
"I'd use caching to improve performance."
[GOOD]
"I'd introduce a caching layer to improve read latency.
The trade-off is that we might serve stale data, but
for this use case, a TTL of 5 minutes is acceptable
because users can tolerate slightly outdated information."
Every design decision has an upside and a downside. Raising the trade-off yourself, before anyone asks, is what shows depth.
Mistake 4: Vague Numbers
[BAD]
"This system should handle a lot of traffic."
[GOOD]
"Based on our earlier estimates of 100 million daily
active users, we need to handle approximately 12,000
requests per second at peak, assuming a 3x peak-to-average
ratio."
Concrete numbers show the interviewer you can think quantitatively.
Mistake 5: Translating Korean Sentence Patterns Directly
[BAD - literal translation from Korean]
"If many users come at the same time, the server becomes
not good."
[GOOD - natural English]
"Under high concurrency, the server may become overwhelmed,
leading to increased latency and potential timeouts."
Carrying Korean thought patterns straight across into English reads unnaturally. Learn the technical phrasing patterns English actually uses.
Interview Preparation Checklist
Use the checklist below to review your English preparation before a system design interview.
Clarifying Requirements
- Have you practiced opening with "Let me clarify the requirements"?
- Can you ask about scale, QPS, and storage capacity in English?
- Can you ask about functional and non-functional requirements separately?
Describing the Architecture
- Can you lay out the whole structure with "At a high level, this system consists of..."?
- Can you state each component's role in one English sentence?
- Can you "walk through" the data flow in order, in English?
Analyzing Trade-offs
- Can you say "The trade-off here is between X and Y" naturally?
- Can you use the "On one hand... on the other hand..." pattern?
- Can you give the reason for a choice concretely, with "because"?
Discussing Scaling
- Can you explain the difference between horizontal and vertical scaling in English?
- Can you identify a bottleneck and propose a fix?
- Can you do a back-of-the-envelope calculation out loud, with real numbers?
Overall Communication
- Do you know how to admit what you do not know: "I'm not entirely sure about the specifics, but my understanding is..."
- Can you respond to the interviewer's feedback: "That's a great point. Let me reconsider..."
- Can you manage time out loud: "Given the time constraint, let me prioritize..."
References
- System Design Interview by Alex Xu - the classic reference for system design interviews
- Designing Data-Intensive Applications by Martin Kleppmann - the bible of data system design
- Grokking the System Design Interview (Educative) - an online learning platform
- ByteByteGo Newsletter - a weekly newsletter on system design
- Tech Interview Handbook - a comprehensive guide to technical interviews generally
Conclusion
English communication in a system design interview does not come together overnight. Practice the expression patterns in this article repeatedly, though, and you will be able to convey your technical thinking effectively when it counts.
The three most important points:
- Always clarify the requirements first: "Let me clarify the requirements first"
- Name the trade-off explicitly: "The trade-off here is between..."
- Back it with concrete numbers: give quantitative evidence instead of an abstract explanation
Add English communication to your technical ability and you can discuss your design with confidence in a system design interview. Practice these expressions the way you would in the room, through mock interviews.