Vocabulary for System Design Interviews

System design interviews test your ability to think about large-scale software architecture — and to explain your thinking clearly in English. Knowing the right vocabulary is not optional: interviewers are listening for specific terms that signal you understand the trade-offs involved.

This guide covers the vocabulary you need, organised by topic.

---

Scalability Vocabulary

These terms come up in almost every system design discussion:

Term	Definition	Example sentence
horizontal scaling	Adding more machines to handle load	“We can scale horizontally by adding more API server instances behind the load balancer.”
vertical scaling	Upgrading the capacity of a single machine	“Vertical scaling is simpler but has a hard ceiling — you can only add so much CPU and RAM to one machine.”
load balancer	Distributes incoming traffic across servers	“The load balancer uses round-robin to distribute requests across our three application servers.”
stateless	Server does not store client session data between requests	“Making the API stateless allows us to scale horizontally without sticky sessions.”
auto-scaling	Automatically adding/removing instances based on demand	“We use auto-scaling to handle traffic spikes during peak hours without over-provisioning.”
sharding	Splitting a database across multiple machines	“We shard by user ID — each shard holds accounts for a specific range.”
partitioning	Dividing data logically (often used interchangeably with sharding)	“Horizontal partitioning splits rows; vertical partitioning splits columns.”

---

Reliability and Availability Vocabulary

“We’re targeting 99.9% availability — that allows us approximately 8.7 hours of downtime per year.”

Term	Definition
SLA (Service Level Agreement)	A contract defining the expected availability or performance
SLO (Service Level Objective)	An internal target, e.g., 99.9% uptime
SLI (Service Level Indicator)	A metric measuring actual performance
failover	Automatically switching to a backup system when the primary fails
replication	Copying data to multiple locations for redundancy
single point of failure	A component whose failure would bring down the entire system
redundancy	Having backup components to avoid single points of failure
graceful degradation	The system continues partially functioning under failure
circuit breaker	Stops retrying a failing service to prevent cascade failures

In context:

“The primary risk in this design is that the database is a single point of failure. I’d add a read replica and automatic failover to address that.”

---

Database Vocabulary

“For this use case, I’d lean towards a relational database — we have well-defined schemas and need ACID guarantees.”

Term	Definition
ACID	Atomicity, Consistency, Isolation, Durability — guarantees for relational databases
BASE	Basically Available, Soft state, Eventually consistent — common in NoSQL
eventual consistency	Data will become consistent across nodes, but not immediately
strong consistency	All reads return the most recent write
CAP theorem	A distributed system can guarantee only two of: Consistency, Availability, Partition tolerance
read replica	A copy of the database used only for read queries
write-through cache	Data is written to cache and database simultaneously
write-back cache	Data is written to cache first, then asynchronously to the database
N+1 problem	Performance issue where one query generates N additional queries

---

Caching Vocabulary

“We can put a cache in front of the database to reduce read latency. I’d use an LRU eviction policy given that access patterns are not uniform.”

Term	Definition
cache hit	Requested data found in cache
cache miss	Requested data not in cache — must fetch from source
cache eviction	Removing data from cache to make room for new entries
LRU (Least Recently Used)	Evicts data not accessed recently
TTL (Time To Live)	How long data stays in cache before expiring
cache invalidation	Removing or updating stale data from cache
CDN (Content Delivery Network)	Distributed servers that cache static assets near users

---

Messaging and Queues Vocabulary

“To decouple the notification service from the order service, I’d introduce a message queue. The order service publishes an event; the notification service consumes it asynchronously.”

Term	Definition
message queue	A buffer that holds messages between producer and consumer
producer / consumer	Services that send / receive messages
pub/sub (publish/subscribe)	Pattern where publishers broadcast events to multiple subscribers
dead letter queue	Holds messages that could not be processed successfully
idempotency	Processing the same message multiple times produces the same result
at-least-once delivery	Message will be delivered, but may arrive more than once
exactly-once delivery	Each message is delivered and processed exactly one time

---

Useful Phrases for System Design Discussions

“Let me start with the high-level architecture and then drill into the components.”

“The bottleneck in this design is the database. Here’s how I’d address that.”

“The trade-off here is consistency versus availability — depending on the requirement, I’d choose differently.”

“Given the scale requirements — 10 million daily active users — horizontal scaling is non-negotiable.”

“I’m making a simplifying assumption here: that reads heavily outnumber writes. Is that consistent with the requirements?”

---

Mastering this vocabulary lets you move smoothly between technical concepts and communicate trade-offs fluently — which is exactly what system design interviews reward.

Navigating Nuance: Phrasing for Collaboration & Clarity

Many developers learning professional English find the subtle differences in phrasing incredibly challenging. It’s not just about knowing what to say; it’s about conveying your meaning precisely and effectively within a team environment. A seemingly small change in wording can dramatically shift the tone of a request, impact feedback received, or even influence the acceptance of a proposed solution. Consider the difference between stating “This needs fixing” versus “I’ve identified a potential performance bottleneck that requires optimization.” The latter immediately frames the issue as something to be addressed proactively and collaboratively.

A common scenario is during a code review. Receiving feedback like “This isn’t readable” can feel dismissive. A more constructive approach, using phrases like “Could we explore refactoring this section for improved readability? Perhaps adding some comments explaining the logic would help,” demonstrates a willingness to discuss and learn, fostering a positive interaction. Similarly, in Slack discussions regarding pull requests, avoid blunt statements. Instead of saying “This is wrong,” try “I’m seeing an issue with [specific aspect]. Could we discuss how best to address this?” Focusing on the what and how, rather than personal judgment, significantly reduces defensiveness and encourages productive problem-solving. Remember, clear communication isn’t just about technical accuracy; it’s about building trust and rapport within your team. Framing requests as “Let’s investigate…” or “I’d like to propose…” shows humility and a desire for shared understanding.

Another frequent challenge is describing the why behind design decisions. Simply stating, “I used this database” isn’t sufficient. Explain the rationale: “We chose PostgreSQL due to its robust transaction management capabilities, which are critical for ensuring data consistency in our high-volume order processing system.” Using phrases like “to ensure scalability,” “to minimize latency,” or “to adhere to best practices” adds context and demonstrates a deeper understanding of the system’s requirements. It also allows reviewers and stakeholders to understand why you made a particular choice, which can be invaluable during discussions about trade-offs.

Finally, don’t shy away from acknowledging uncertainty. Phrases like “I’m still exploring options for…” or “Let’s prototype this to evaluate its feasibility” are perfectly acceptable – demonstrating that you’re open to iterating and adapting your approach based on new information.

# Example: Using `docker compose` to start a simple web application
docker compose up -d --build

This command demonstrates the use of docker compose, a tool for defining and running multi-container Docker applications. The -d flag runs the containers in detached mode (in the background), and --build ensures that any necessary images are built before starting the application. It’s a common phrase used to describe deploying and managing complex systems, and understanding its components is crucial when discussing scalability and operational concerns during system design interviews.