Terms & Acronyms — One-Stop Glossary
Why this page exists
Most guides throw TPS, NIC, p99 at you and assume you know them — so the
real idea never lands. This is the one-stop decoder for the vocabulary used across system design, performance,
and infrastructure. It deliberately includes standard industry terms you’ll meet in interviews even if they don’t
appear elsewhere in this guide. Skim it once; return to it whenever a term trips you up.
For the companion cheat-sheet on laws, capacity chain, and failure modes, see the
Systems Cheat-Sheet;
for raw number anchors, see Numbers & Units You Must Know Cold.
Rate & throughput — the “…PS” family (where most confusion lives)
| Term | Means | Note |
|---|---|---|
| QPS | Queries Per Second | Read-ish requests hitting a service |
| TPS | Transactions Per Second | Heavier than a query — a write + durability (commit) |
| RPS | Requests Per Second | Generic HTTP requests; often used like QPS |
| IOPS | I/O Operations Per Second | Disk/SSD read-write ops (SSD ~10K–100K) |
| Throughput | Work done per unit time | req/s or MB/s |
| Bandwidth | Max data rate of a link | The ceiling (e.g. 1 Gbps), not the actual rate |
| Goodput | Useful throughput | Throughput minus retransmits/overhead |
Latency — time for one operation
| Term | Means |
|---|---|
| Latency | Time for a single operation (ms). Throughput = how many; latency = how fast each. |
| RTT | Round-Trip Time — request out + response back (same-DC ~0.5 ms, cross-continent ~150 ms); the latency floor of any request |
| p50 / p95 / p99 | Percentile latency. p99 = 99% of requests are faster than this — the “tail” slow users feel. Design for p99, not the average. |
| Tail latency | The slow end of the distribution (p99+); dominates user-perceived slowness |
| Jitter | Variation in latency between requests |
| HOL blocking | Head-of-line blocking — one stuck request delays those queued behind it |
Hardware & network
| Term | Means |
|---|---|
| NIC | Network Interface Card — the machine’s network port; its speed caps bandwidth (1/10/25 Gbps) |
| vCPU / core | A unit of parallel compute; a thread runs on a core |
| RAM | Main memory — ~100 ns access, volatile |
| Cache (L1/L2/L3) | Tiny ultra-fast CPU memory (~1–10 ns) |
| SSD vs HDD | SSD ~500 MB/s seq, ~100 µs random; HDD seek ~10 ms |
| ⚠️ Gbps vs GB/s | The #1 estimation trap. Network = bits; storage = bytes. 1 Gbps = 125 MB/s — divide by 8. |
Protocols & web
| TCP / UDP | Reliable/ordered vs fast/lossy transport |
| IP | Network-layer host addressing (see Networking Fundamentals) |
| HTTP/1.1 · 2 · 3 | Web protocol generations; HTTP/3 runs on QUIC (UDP-based) |
| TLS / mTLS | Transport encryption; mTLS = both sides present certificates |
| REST / gRPC / GraphQL | API styles (see Building Blocks) |
| WebSocket / SSE | Full-duplex / server-push real-time channels |
| DNS / CDN / POP | Name resolution / edge content delivery / point of presence — the edge location that serves it |
Security & identity
| AuthN vs AuthZ | Authentication (who you are) vs authorization (what you may do) — see Authentication / Authorization |
| OAuth 2.0 / OIDC | Delegated authorization / the identity layer built on top of it (see OAuth 2.0 & OIDC traced) |
| JWT | JSON Web Token — signed claims in a token; enables stateless sessions (see Session vs Token Auth) |
| API key vs bearer token | Long-lived per-client credential vs short-lived token presented in the Authorization header |
Data & consistency
| ACID / BASE | Strong transactional vs eventually-consistent guarantees |
| CAP / PACELC | Consistency-availability-partition trade-off; PACELC adds the latency dimension |
| Quorum (N/R/W) | Replicas / read-set / write-set; R + W > N guarantees the read and write sets overlap, so a read can see the latest acknowledged write — it does not give linearizability by itself (see quorum caveat) |
| Consistency models | Linearizable, sequential, causal, eventual, read-your-writes, monotonic reads — the spectrum of what a read is guaranteed to return (see The Consistency Spectrum) |
| TTL | Time To Live — expiry for cached/stored data |
| WAL | Write-Ahead Log — durability + crash recovery |
| CDC | Change Data Capture — stream a DB’s changes downstream |
| MVCC | Multi-Version Concurrency Control — readers don’t block writers |
| Idempotency | Doing it twice = same result as once (safe retries) |
| FK / PK | Foreign key / primary key |
| UUID / ULID | 128-bit unique IDs (ULID is time-sortable) |
Reliability & operations
| SLA / SLO / SLI | Agreement (the promise) / Objective (internal target) / Indicator (measured metric) |
| Availability (“nines”) | 99.9% ≈ 8.8 h down/yr · 99.99% ≈ 52 min · 99.999% ≈ 5 min |
| RPO / RTO | Disaster recovery: how much data you can lose / how fast you must recover |
| MTBF / MTTR | Mean time between failures / mean time to recovery |
| Error budget | Allowed unreliability (1 − SLO); spend it on shipping speed |
| Circuit breaker / Backpressure | Stop calling a failing dependency / push load back to slow producers |
Scaling & architecture
| Horizontal / Vertical scaling | Add more machines / make one machine bigger |
| Sharding / Partitioning | Split data across nodes by a key |
| Consistent hashing | Minimal-rebalance key→node mapping |
| LB / API Gateway / BFF | Load balancer / single entry point / backend-for-frontend |
| CQRS / Saga / Outbox / DLQ | Read-write split / distributed transaction / reliable publish / dead-letter queue |
| Object / Block / File storage | S3-style blobs / raw volumes / filesystems |
| B-tree / LSM-tree | Read-optimized vs write-optimized storage engines |
Common abbreviations
| CI / CD | Continuous Integration / Continuous Delivery (or Deployment) — automate build, test, and release |
| CAS | Compare-And-Swap — atomic read-modify-write primitive used in lock-free algorithms |
| CRDT | Conflict-Free Replicated Data Type — data structure that merges replicas without coordination |
| ETL / ELT | Extract-Transform-Load / Extract-Load-Transform — data-pipeline patterns |
| FaaS / Serverless | Function-as-a-Service — stateless functions triggered by events; the provider manages the servers |
| ORM | Object-Relational Mapper — maps code objects to DB rows |
| VPC / VPN | Virtual Private Cloud / Virtual Private Network — isolated cloud network / encrypted tunnel |
Related pages: Capacity Estimation, System Design Building Blocks, Caching, Databases, Observability & SRE.
Glossary in action: a photo upload in one breath
Suppose a user in Berlin opens a photo-sharing app and uploads a picture. Here is the same sentence a senior engineer would say in a design review, with every acronym decoded in context.
The mobile client resolves the API hostname through DNS, then opens a TLS connection to the nearest CDN edge (POP) for static assets. For the upload itself it bypasses the CDN and hits the API Gateway / LB, which routes the request to a K8s pod in the eu-central-1 region. The pod authenticates the user, writes the image bytes to object storage (S3-style), and inserts the metadata row into the SQL primary. To keep the home feed fast, it invalidates the Redis cache entry for that user and publishes an async thumbnail-generation job to Kafka. The upload call must complete within the p99 latency budget of 300 ms; the operations team tracks this as an SLI, targets a 300 ms SLO, and reports it against the customer-facing SLA. If the pod logs an error, an OTel trace spans DNS → TLS → LB → pod → SQL → Redis → Kafka so the on-call engineer can see which hop caused the tail latency.
That one sentence exercised DNS, TLS, CDN, POP, API Gateway, LB, K8s, object storage, SQL, Redis, Kafka, p99, SLI, SLO, SLA, and OTel — and each term’s role is visible because the scenario, not the alphabet, drives the explanation.
Categorized index: find the term by the problem you are solving
Use this index when you know the category of the decision and want the vocabulary that goes with it. Each term links to its single definition above — nothing is redefined here.
| Problem you are solving | The vocabulary that goes with it |
|---|---|
| Networking & traffic | DNS, CDN / POP, TCP / UDP, HTTP/1.1·2·3 / QUIC, WebSocket / SSE, LB / API Gateway / BFF, NIC, RTT, Bandwidth / Goodput / Throughput |
| Storage & data layout | SSD vs HDD, WAL, CDC, MVCC, TTL, FK / PK, UUID / ULID, Object / Block / File storage, B-tree / LSM-tree |
| Consistency & coordination | ACID / BASE, CAP / PACELC, Quorum (N/R/W), Consistency models, Idempotency, CRDT, CAS |
| Security & identity | AuthN vs AuthZ, OAuth 2.0 / OIDC, JWT, API key vs bearer token, TLS / mTLS, VPC / VPN |
| SRE & operability | SLA / SLO / SLI, Availability (“nines”), RPO / RTO, MTBF / MTTR, Error budget, Circuit breaker / Backpressure |
When NOT to treat the glossary as design
- Acronym recognition ≠ ability to defend a trade-off — always open the full topic page.
- Do not invent architecture from buzzwords (CQRS+ES+mesh) without a forcing problem.
Interviewer follow-ups & drills
- Define RPO vs RTO in one sentence each. RPO = how much data you may lose; RTO = how long until service is back.
- Ops use: during incident, shared terms (SLO, error budget, quorum) speed coordination.
Same word, two meanings — the trap pairs interviewers spring
The test: can you answer “is a CP system consistent in the ACID sense?” — not necessarily; the two words share a spelling, not a definition.
| Word | Meaning #1 | Meaning #2 |
|---|---|---|
| Consistency | CAP: every read sees the latest write. | ACID: invariants preserved across a transaction. |
| Partition | Network partition: nodes can’t talk to each other. | Data partition / shard: data split across nodes by a key. |
| Availability | CAP: every request gets a non-error response. | Uptime SLA: fraction of time the service is up. |
| Durability vs availability | ACID durability: committed data survives a crash. | Service availability: data can be fully durable while the service is down (see the durability-vs-availability correction). |
| Replication | For durability: extra copies so data survives node loss. | For read scale: extra copies so reads spread out — same copies, a different requirement drives the count. |
| Latency vs response time | Latency: the service time of the operation itself. | Response time: service time plus queueing wait — what the user actually feels. |
Formulas are standard/public-domain engineering math. Approach and reference-table format adapted from the System Design Primer (CC BY 4.0), Jeff Dean’s latency numbers, the DesignGurus capacity-estimation guide, and Little’s Law.
🤖 Don't fully get this? Learn it with Claude
Stuck on Terms & Acronyms — One-Stop Glossary? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Terms & Acronyms — One-Stop Glossary** (System Design) and want to truly understand it. Explain Terms & Acronyms — One-Stop Glossary from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **Terms & Acronyms — One-Stop Glossary** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **Terms & Acronyms — One-Stop Glossary** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **Terms & Acronyms — One-Stop Glossary** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.