Vocabulary for System Design Interviews
The essential English vocabulary for system design interviews — scalability, reliability, databases, and distributed systems terms explained with examples.
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 --buildThis 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.