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.