System Design Interview English Expressions: From Architecture Explanation to Trade-off Discussion

• Introduction
• 1. Clarifying Requirements
  • Framing the Interview at the Start
  • Clarifying Functional Requirements
  • Non-Functional Requirements and Scale Estimation
  • Bounding Scope and Setting Priorities
• 2. Describing the Architecture
  • Introducing the High-Level Architecture
  • Explaining Component Roles
  • Patterns for Describing the Data Flow
  • Justifying Technology Choices
• 3. Discussing Scalability
  • Horizontal vs. Vertical Scaling
  • Explaining the Caching Strategy
  • Database Scaling and Partitioning
  • Identifying and Fixing Bottlenecks
• 4. Analyzing Trade-offs
  • Framing the Trade-off
  • Comparing the Alternatives
  • Patterns for Justifying a Decision
• 5. Explaining the Data Model
  • Describing Entities and Relationships
  • Justifying the Database Choice
  • Indexing and Query Optimization
• 6. A Full Interview Simulation
• 7. Key Expression Comparison Table
  • Core Vocabulary
• 8. Fill-in-the-Blank Quiz
• 9. Speaking Practice
  • Practice 1: Explaining an Architecture
  • Practice 2: Analyzing a Trade-off
  • Practice 3: Responding on Scalability
  • Practice 4: Designing for Failure
• Conclusion
• References

Introduction

The system design interview is the central gate in senior engineering hiring. At FAANG companies — Meta, Apple, Amazon, Netflix, Google — and across the global tech industry, this round does not simply measure technical knowledge; it evaluates your ability to design a complex system while conveying your own thinking clearly.

The biggest difficulty Korean engineers face in a system design interview is not a shortage of technical skill. Most are technically more than capable, but they struggle to convey their design intent in English in a structured way. Turning the thought “a cache would probably help here” into a clear English sentence — "I would introduce a caching layer here to reduce the read latency on our database" — is not easy.

This article sets out, systematically, the core English expression patterns for each stage of a system design interview. It is not a bare list of phrases: for each one it covers why it works, when to use it, and the impression it leaves on the interviewer. Simulations, a vocabulary comparison table, and a quiz are there so you can make what you learn your own immediately.

The core skills this article covers are the following.

• Question patterns for checking the requirements systematically at the start of the interview
• A speaking style that explains a complex architecture clearly, top-down
• Expressions that propose a scalability strategy with quantitative backing
• Trade-off discussion patterns that weigh the pros and cons of a design decision evenly
• Expressions that justify a data model and schema choice logically

1. Clarifying Requirements

A system design interview always starts with clarifying the requirements. When the interviewer says "Design a URL shortener" or "Design a chat system," diving straight into the design is the most common mistake. What the interviewer is evaluating is how you turn an ambiguous problem into a concrete one, and whether you can ask the right questions.

Framing the Interview at the Start

Explaining your approach first, as soon as the interview begins, matters. Doing so tells the interviewer you are someone who thinks in structures.

"Before jumping into the design, I'd like to spend a few minutes
clarifying the requirements and understanding the constraints."
(Buys you the clarification time explicitly, so it does not look like stalling.)

"I'll start by asking some clarifying questions, then outline
a high-level design, and iteratively refine it."
(Names all three phases up front, which sets the interviewer's expectations.)

"My approach will be to first understand the functional and
non-functional requirements, then work through the system
design top-down."
(Splits functional from non-functional and commits to a top-down order.)

Clarifying Functional Requirements

Functional requirements define what the system has to do. You need questions that pin down the core features and the boundaries of scope.

"What are the core use cases we need to support?"
(The broadest opener: it gets the interviewer to name the must-have flows.)

"Should the system support real-time updates, or is
eventual consistency acceptable?"
(Separates real-time delivery from eventual consistency before you design for either.)

"Do we need to support both mobile and web clients,
or can I focus on one platform initially?"
(Establishes how many client platforms are in scope.)

"Is there a requirement for offline support or
graceful degradation?"
(Surfaces the resilience requirements early rather than at the end.)

Non-Functional Requirements and Scale Estimation

Non-functional requirements define the system's quality attributes. Doing a back-of-the-envelope estimation alongside them leaves a strong impression on the interviewer.

"Let me do a quick back-of-the-envelope calculation to
estimate the scale."
(Signals that you will put a number on the scale before designing for it.)

"If we have 100 million daily active users, and each user
generates an average of 10 requests per day, that gives us
roughly 1 billion requests per day, or about 12,000 QPS."
(Shows the arithmetic out loud, which is exactly what the interviewer wants to see.)

"What's the expected read-to-write ratio? I'm assuming
it's heavily read-biased, maybe 100:1?"
(Read-to-write ratio drives almost every later decision, so ask it early.)

"Are there any specific latency requirements? For example,
should the 99th percentile response time be under
200 milliseconds?"
(Turns a vague "it should be fast" into a testable number.)

"What's our availability target? Five nines, or is
99.9 percent sufficient?"
(Availability target decides how much redundancy the design has to carry.)

Bounding Scope and Setting Priorities

You cannot cover everything inside a limited interview slot — usually 45 to 60 minutes — so actively bounding the scope matters.

"Given the 45-minute time constraint, I'd propose we focus on
the core messaging flow first, and then discuss notification
delivery and media handling if time permits."
(Names the time constraint, then commits to a core-first order.)

"Let me prioritize the requirements. I see the URL shortening
and redirection as P0, analytics as P1, and custom domains
as P2."
(P0/P1/P2 language shows you prioritize the way a working engineer does.)

"I'll table the authentication and authorization aspects for now
and assume we have an existing auth service we can integrate with."
(Parks a whole subsystem explicitly instead of quietly ignoring it.)

2. Describing the Architecture

Once the requirements are settled, you move on to describing the whole architecture. The key at this stage is to work top-down while conveying the role of each component and how the components interact.

Introducing the High-Level Architecture

Start the explanation while you draw the big picture on the whiteboard, or in an online diagramming tool.

"Let me sketch out the high-level architecture first.
At the topmost level, I see three main layers: the client
layer, the application layer, and the data layer."
(Announcing the layer count before drawing gives the interviewer a frame to follow.)

"The system will be composed of several microservices,
each responsible for a single bounded context."
(One bounded context per service is the phrase that signals real service-design thinking.)

"I'm envisioning a distributed architecture with
a load balancer at the entry point, multiple stateless
application servers, and a replicated database cluster."
(Names the entry point, the stateless tier, and the data tier in one breath.)

Explaining Component Roles

When you describe a component, be explicit about its responsibility, its input and output, and its relationship to the other components.

"The API Gateway serves as the single entry point for all
client requests. It handles authentication, rate limiting,
and request routing to the appropriate backend service."
("Serves as the single entry point" is the standard formula for a gateway.)

"This service is responsible for generating unique short URLs
and persisting the mapping between the short URL and the
original URL."
("Is responsible for" plus a verb pair is the cleanest way to state a service's job.)

"The notification service acts as a fan-out component. When
a new message arrives, it distributes push notifications to
all relevant subscribers."
("Acts as a fan-out component" names the pattern, not just the behavior.)

Patterns for Describing the Data Flow

Walking through how data moves through the system, step by step, is a pattern interviewers love. Reach for the phrase "walk through."

"Let me walk you through a typical write path. When a user
creates a new post, the request first hits our load balancer."
("Walk you through a typical write path" sets up a step-by-step narration.)

"From there, the load balancer forwards the request to one of
the application servers using a round-robin strategy."
("From there" carries the reader from one hop to the next without restating context.)

"The application server validates the input, enriches the data
with metadata, and then writes it to the primary database."
(Three verbs in sequence keep a multi-step operation easy to follow.)

"Simultaneously, a message is published to the event bus,
which triggers the indexing service to update the search index
and the notification service to alert followers."
("Simultaneously" marks the asynchronous branch of the flow.)

Justifying Technology Choices

Do not simply name a technology; give the reason why you chose it alongside it.

"I'm choosing Redis as the caching layer because it provides
sub-millisecond latency and supports various data structures
like sorted sets, which are ideal for our leaderboard feature."
(Names one property of Redis and ties it directly to a feature requirement.)

"For the message queue, I'd go with Kafka over RabbitMQ
because we need high throughput, message durability,
and the ability to replay events."
("X over Y because" is the compact form for a head-to-head technology choice.)

"I'd recommend using a NoSQL database like DynamoDB here
because our access patterns are well-defined and we need
to scale horizontally without worrying about sharding complexity."
(Justifies NoSQL by access pattern rather than by preference.)

3. Discussing Scalability

Scalability is the central topic of a system design interview. Interviewers want to hear how the system responds to growing traffic and how you resolve its bottlenecks.

Horizontal vs. Vertical Scaling

"For the application tier, I'd go with horizontal scaling
rather than vertical scaling. Adding more instances behind
the load balancer is more cost-effective and provides better
fault tolerance than scaling up a single machine."
(States the choice, then gives two reasons: cost and fault tolerance.)

"The beauty of making these services stateless is that we can
scale them out independently based on demand."
("The beauty of X is that" is a natural way to name a design benefit.)

"We might start with vertical scaling for the database in
the short term, but we should plan for sharding as we
approach the limits of a single node."
(Concedes a short-term choice while committing to the long-term one.)

Explaining the Caching Strategy

"To handle the high read traffic, I'd introduce a multi-level
caching strategy. First, a CDN for static assets. Second,
an application-level cache using Redis for frequently accessed
data. Third, a local in-memory cache for hot data."
(First, second, third — the numbered form makes a multi-level design easy to hold.)

"For the caching strategy, I'd use a write-through pattern
for data that needs strong consistency, and a cache-aside
pattern for data where slight staleness is acceptable."
(Matches each cache pattern to a consistency requirement.)

"The cache hit ratio is critical here. If we can achieve
a 95 percent cache hit rate, we reduce the database load
by 20x, which would bring our P99 latency well under
the 200-millisecond target."
(Turns the cache into a number, and ties that number back to the latency target.)

Database Scaling and Partitioning

"As the data volume grows, we'll need to partition the database.
I'd suggest range-based sharding on the timestamp for time-series
data, or hash-based sharding on the user ID for user-centric data."
(Names two sharding strategies and the data shape each one suits.)

"To avoid the hotspot problem with hash-based sharding,
we could use consistent hashing, which minimizes data
redistribution when we add or remove nodes."
(Raises the hotspot problem yourself, then answers it with consistent hashing.)

"For read scalability, I'd set up read replicas. The primary
handles all writes, and reads are distributed across multiple
replicas. This gives us a read throughput that scales linearly
with the number of replicas."
(Explains read replicas and states the scaling property they give you.)

Identifying and Fixing Bottlenecks

"The bottleneck in this design is the single database write path.
Under peak load, all write operations funnel through one primary
node, which could become saturated."
(Naming the bottleneck yourself is what senior candidates do.)

"To alleviate this bottleneck, I'd introduce a write-behind
queue. Instead of writing directly to the database, the application
writes to a fast message queue, and a background worker processes
the writes in batches."
("To alleviate this bottleneck, I'd introduce" is the standard fix-proposal frame.)

"Another potential bottleneck is the fan-out on read. If a user
follows thousands of accounts, assembling their timeline
could be expensive."
("Another potential bottleneck" keeps the analysis going past the first answer.)

4. Analyzing Trade-offs

Trade-off analysis is the core competence of a senior engineer. Interviewers rate highly the candidate who understands there is no silver bullet and can weigh the pros and cons of each design decision evenly.

Framing the Trade-off

"There's a fundamental trade-off here between consistency and
availability. Following the CAP theorem, since we're building
a distributed system, we need to decide which one to prioritize
when network partitions occur."
(Naming CAP explicitly shows you know which constraint you are working under.)

"The trade-off I see here is between system complexity and
performance. We could get a 10x improvement in query latency
by denormalizing the data, but that introduces data
consistency challenges."
("The trade-off I see here is between X and Y" states both sides in one sentence.)

"We're essentially trading off development velocity for
operational simplicity. A monolithic approach would be faster
to build initially, but a microservices architecture gives us
better long-term scalability and team autonomy."
("We're essentially trading off X for Y" is the compact form of the same move.)

Comparing the Alternatives

When you compare several options, listing the pros and cons in a structure is what works.

"Let me compare two approaches. Option A is a push-based model,
where we precompute timelines. Option B is a pull-based model,
where we compute timelines on demand."
(Labeling the options A and B lets you refer back to them without repeating the description.)

"The advantage of Option A is lower read latency since the
timeline is precomputed. The downside is higher write
amplification and storage cost."
("The advantage is... The downside is..." is the two-sided formula in its shortest form.)

"Given our requirement of sub-100-millisecond read latency and
the fact that our system is heavily read-biased, I'd lean toward
Option A, the push-based model, and optimize for the celebrity
problem separately."
(Ties the choice back to the stated requirement, then flags the exception separately.)

Patterns for Justifying a Decision

Once you have made a design decision, justify clearly why you made it.

"I'm going with this approach because it aligns with our primary
requirement of high availability. The slight inconsistency window
of a few seconds is acceptable for our use case."
("Because it aligns with our primary requirement of X" ties the decision to the brief.)

"The reason I prefer eventual consistency here is that user
experience data shows that users rarely notice a 2-3 second
delay in feed updates, but they absolutely notice downtime."
(Grounds the choice in user behavior rather than in engineering preference.)

"If I had to revisit this decision, the trigger would be if our
consistency requirements changed, for example, if we needed to
support financial transactions."
(Naming the trigger that would reverse the decision is a strong senior signal.)

5. Explaining the Data Model

The data model is the foundation of the system. When you explain it in an interview, cover the entity relationships, the access patterns, and the indexing strategy together.

Describing Entities and Relationships

"Let me define the core entities first. We have Users, Posts,
and Comments. A User can create multiple Posts, and each Post
can have multiple Comments. This is a one-to-many relationship
in both cases."
(Defining entities before relationships keeps the model easy to follow.)

"For the follower relationship, we have a many-to-many
relationship between Users. I'd model this as a separate
adjacency table with follower_id and followee_id."
(Names the cardinality and the concrete table that implements it.)

"I'm intentionally denormalizing the author name into the
Post table to avoid an expensive join on every read operation."
("I'm intentionally denormalizing" tells the interviewer this is a choice, not an oversight.)

Justifying the Database Choice

"For the main user data, I'd use a relational database like
PostgreSQL because we need ACID transactions for user account
operations and the data has clear relational structure."
(Two reasons: transactional requirement and relational shape.)

"For the message history, I'd choose Cassandra because it excels
at write-heavy workloads and provides linear scalability.
The access pattern is simple: we always query by conversation ID
and sort by timestamp."
(Justifies the choice by workload profile and by the exact query pattern.)

"I'd store the media files in an object store like S3,
and only keep the metadata and reference URLs in our
primary database. This separation of concerns keeps the
database lean and the storage cost manageable."
("Separation of concerns" names the principle behind splitting blobs from metadata.)

Indexing and Query Optimization

"I'd create a composite index on user_id and created_at
to efficiently support the query pattern of fetching
a user's recent posts."
(States the index and the query pattern it exists to serve.)

"For the search functionality, I'd use an inverted index
powered by Elasticsearch. The primary database serves as
the source of truth, and we asynchronously sync data
to the search index."
("Source of truth" plus "asynchronously sync" is the standard search-index framing.)

"To avoid full table scans, I'd partition the analytics data
by date range, so queries that filter by time period only
need to scan the relevant partitions."
(Explains partitioning through the scan it avoids, not through the mechanism.)

6. A Full Interview Simulation

Here is a simulation of how a real system design interview unfolds. The topic is "Design a URL Shortener (like bit.ly)".

[Interviewer] "Let's design a URL shortening service, similar to bit.ly.
How would you approach this?"

[Candidate] "Great, that's an interesting problem. Before I start
designing, I'd like to clarify a few requirements.

First, on the functional side: Should the system support
custom aliases, or only auto-generated short URLs? And do we
need analytics, like click tracking and geographic data?"

[Interviewer] "Let's support both auto-generated and custom aliases.
Yes, basic analytics would be nice."

[Candidate] "Got it. Now for scale: what's the expected volume of
URL shortening requests? Are we talking millions per day?"

[Interviewer] "Assume 100 million new URLs per month, and a 10:1
read-to-write ratio for redirects."

[Candidate] "Okay, let me do the math. 100 million writes per month
is roughly 40 writes per second on average. With a 10:1
read ratio, that's about 400 redirects per second. We should
design for peak traffic of maybe 5-10x that, so around
2,000 to 4,000 reads per second.

For storage, if the average URL mapping is about 500 bytes
and we store for 5 years, that's roughly 3 terabytes.
That's manageable with a well-designed database setup.

Now let me outline the high-level architecture. I see three
main components:

First, a URL shortening service that takes a long URL and
returns a short one. It generates a unique key, stores the
mapping, and returns the short URL.

Second, a URL redirection service that receives a short URL,
looks up the original URL, and issues an HTTP 301 or 302
redirect.

Third, an analytics service that tracks each redirect event
for reporting purposes.

For the key generation, I'd use a base62 encoding of a
counter or a hash. With 7 characters in base62, we get
about 3.5 trillion unique URLs, which is more than enough.

For the database, I'd go with a NoSQL key-value store
because our access pattern is simple: given a short key,
return the long URL. This is a perfect fit for something
like DynamoDB or Redis.

The trade-off between 301 and 302 redirects is worth
discussing. A 301 is a permanent redirect, which means
browsers will cache it and bypass our service on subsequent
requests. This reduces our server load but means we lose
analytics data. A 302 is a temporary redirect, so the
browser will always come to us first, giving us accurate
click tracking but at higher server load.

Given that analytics is a requirement, I'd use 302 redirects
by default and offer 301 as an option for users who don't
need analytics.

For scalability, I'd put the redirection service behind
a load balancer with auto-scaling. Since the service is
stateless, scaling horizontally is straightforward.
I'd also add a caching layer with Redis to handle hot URLs
that get millions of clicks."

[Interviewer] "Good. What about the availability and reliability
of the system?"

[Candidate] "For availability, I'd deploy across multiple
availability zones. The key-value store would have
cross-region replication for disaster recovery.

For reliability, I'd implement a circuit breaker pattern
between services. If the analytics service is down,
the redirect should still work. We can buffer analytics
events in a message queue and process them when the
analytics service recovers.

I'd also add monitoring and alerting on key metrics:
redirect latency at the P99 level, error rates, and
cache hit ratios. If the cache hit ratio drops below
90 percent, that's an early warning sign that we might
need to scale the cache layer."

7. Key Expression Comparison Table

In a system design interview, two phrasings can carry the same meaning and still leave very different impressions. Compare the beginner and advanced phrasings in the table below.

Core Vocabulary

8. Fill-in-the-Blank Quiz

Fill each blank with the right English expression. Every sentence is a pattern that recurs in system design interviews.

Quiz 1. Opening a scale estimate:

"Let me do a quick __________ calculation to estimate the scale of this system."

Quiz 2. Explaining horizontal scaling:

"We can __________ scale this service by adding more instances behind the load balancer."

Quiz 3. Discussing cache hit rate:

"If we can achieve a 95 percent cache ________ rate, we can significantly reduce the database load."

Quiz 4. Presenting a trade-off:

"The __________ here is between consistency and availability."

Quiz 5. Starting to explain a data flow:

"Let me ________ you ________ the data flow for a typical read request."

Quiz 6. Explaining why you chose a technology:

"I'd ________ for Kafka because it provides high throughput and message durability."

Quiz 7. Identifying a bottleneck:

"The __________ in this design is the single-threaded write path to the database."

Quiz 8. Discussing API idempotency:

"We should make this API __________ so that retries don't create duplicate entries."

Quiz 9. Discussing an availability target:

"Our availability target is five ________, which translates to less than 5.26 minutes of downtime per year."

Quiz 10. Proposing asynchronous processing:

"I'd __________ the image processing from the upload flow by putting it on a message queue."

9. Speaking Practice

Read each scenario below and build an answer in English. Say it out loud if you can. A sample answer follows each scenario.

Practice 1: Explaining an Architecture

Scenario: the interviewer says "Design a chat application like Slack." Explain the high-level architecture.

[Sample answer]

"I'd architect this as a set of microservices. At the top level,
we have the client applications connecting through WebSocket
connections for real-time messaging.

The WebSocket Gateway manages persistent connections with
clients and handles message routing. Behind it, we have
a Message Service that processes incoming messages, persists
them to the database, and publishes events.

For real-time delivery, I'd use a pub-sub system. When a user
sends a message to a channel, the Message Service publishes
it to the channel's topic. The WebSocket Gateway subscribes
to relevant topics and pushes messages to connected clients.

For message persistence, I'd use Cassandra for the message
store, optimized for the write-heavy workload and the access
pattern of fetching messages by channel ID sorted by timestamp.

I'd also have a separate Presence Service that tracks which
users are online, using Redis with TTL-based expiry to manage
user heartbeats."

Practice 2: Analyzing a Trade-off

Scenario: the interviewer asks "Should we use a SQL or NoSQL database for the user profile service?" Analyze the trade-off.

[Sample answer]

"This is a great question, and the answer depends on our
specific requirements. Let me analyze the trade-offs.

For a user profile service, a SQL database like PostgreSQL
offers strong consistency, ACID transactions, and flexible
querying with JOINs. This is beneficial if we need complex
queries across related data, like fetching a user's profile
along with their subscription status and billing information.

On the other hand, a NoSQL database like DynamoDB offers
better horizontal scalability and predictable performance at
any scale. If our access pattern is simple, primarily looking
up a profile by user ID, NoSQL gives us single-digit
millisecond latency regardless of the data volume.

Given that user profiles typically have a well-defined schema
and we might need to do complex queries for admin tools and
analytics, I'd lean toward PostgreSQL for the primary
user profile store. However, I'd cache the frequently
accessed profile data in Redis to handle the high read
throughput from the application layer.

The key consideration is that PostgreSQL can handle our
scale if we implement read replicas. If we were at the
scale of billions of users, I'd reconsider and potentially
use DynamoDB with a separate analytics pipeline."

Practice 3: Responding on Scalability

Scenario: the interviewer asks "Your system is handling 10,000 QPS now. How would you handle a 100x increase in traffic?"

[Sample answer]

"A 100x traffic increase from 10,000 to 1 million QPS is
a significant jump, so I'd approach this in multiple phases.

First, the low-hanging fruit: I'd aggressively optimize our
caching strategy. If we can push our cache hit ratio from
80 to 98 percent, that alone reduces the database load by
10x. I'd implement a multi-tier cache with a local in-process
cache, a distributed Redis cluster, and a CDN for static
and semi-static content.

Second, I'd horizontally scale the stateless application
tier. Since our services are containerized, I'd configure
auto-scaling policies based on CPU utilization and request
queue depth.

Third, and this is the hardest part, the database layer.
I'd shard the database using consistent hashing on the
primary access key. For our use case, sharding by user ID
distributes the load evenly. I'd also separate the read
and write paths, with dedicated read replicas in each
region.

Fourth, I'd introduce asynchronous processing wherever
possible. Any operation that doesn't need to be synchronous,
like analytics event recording, notification delivery, or
search index updates, should go through a message queue.

Finally, I'd set up comprehensive monitoring with dashboards
showing QPS per service, latency distributions, error rates,
and resource utilization. This gives us visibility to
proactively identify bottlenecks before they cause user
impact."

Practice 4: Designing for Failure

Scenario: the interviewer asks "How would you handle a scenario where one of your downstream services goes down?"

[Sample answer]

"Resilience to downstream failures is critical. I'd implement
several defense-in-depth strategies.

First, the circuit breaker pattern. If a downstream service
starts returning errors above a threshold, say 50 percent
error rate over 30 seconds, the circuit breaker trips and we
stop sending requests to that service. Instead, we return
a degraded response or fall back to cached data.

Second, I'd implement retry logic with exponential backoff
and jitter. This prevents thundering herd problems when the
downstream service recovers.

Third, for critical paths, I'd design graceful degradation.
For example, if the recommendation service is down, the
application should still serve the core content, just without
personalized recommendations. The user experience degrades
slightly rather than failing completely.

Fourth, I'd use bulkheads to isolate failures. Each
downstream dependency gets its own thread pool and connection
pool, so a slow or failing service doesn't consume all
the resources and cascade failures to other services.

Finally, I'd set up health checks and automated failover.
If a primary instance fails, traffic automatically routes
to a healthy instance within seconds."

Conclusion

Doing well in a system design interview takes both technical knowledge and English communication. Here is a summary of the expressions covered in this article.

Core patterns for clarifying requirements:

• "Before jumping into the design, I'd like to clarify..." (checking before you design)
• "Let me do a back-of-the-envelope calculation..." (estimating scale)
• "Given the time constraint, I'd like to focus on..." (bounding scope)

Core patterns for describing the architecture:

• "Let me sketch out the high-level architecture..." (the top-level view)
• "Let me walk you through the data flow..." (narrating the data flow)
• "I'm choosing X because..." (justifying a technology)

Core patterns for discussing scalability:

• "I'd go with horizontal scaling rather than..." (the scaling strategy)
• "The bottleneck in this design is..." (identifying the bottleneck)
• "To alleviate this, I'd introduce..." (proposing the fix)

Core patterns for analyzing trade-offs:

• "The trade-off here is between X and Y..." (framing the trade-off)
• "The advantage of Option A is... The downside is..." (comparing pros and cons)
• "I'm going with this approach because..." (justifying the decision)

The single most effective way to prepare for a system design interview is to actually say the design out loud in English. Stand at a whiteboard alone, design a system for 45 minutes, and narrate it in English. It will feel awkward at first, but repeat the patterns in this article and technical English will settle into place.

An interview is, in the end, communication. A clear explanation matters more than a perfect design. Sharing your thinking transparently, admitting the trade-offs honestly, and responding flexibly to the interviewer's feedback is what makes a system design interview go well.

References

• System Design Interview - An insider's guide by Alex Xu - the book widely called the bible of system design interview prep
• Grokking the System Design Interview - Educative - an interactive system design interview course
• Martin Kleppmann - Designing Data-Intensive Applications - the textbook on designing data-intensive applications
• Google SRE Book - Site Reliability Engineering - Google's public book on site reliability engineering
• AWS Well-Architected Framework - AWS's framework for well-architected systems
• High Scalability Blog - case studies of large-scale system architecture
• ByteByteGo - System Design Newsletter by Alex Xu - a weekly system design newsletter with visual explainers