Free lesson · System Design Fundamentals
30 Must-Know Concepts: A Vocabulary Primer
Lesson 1.5 - 30 Must-Know Concepts: A Vocabulary Primer
The fifth and final lesson of Module 1.
This lesson introduces 30 concepts you'll encounter repeatedly throughout the course. The treatment here is deliberately shallow - one paragraph per concept, enough to recognize the term and have a rough mental model. Each concept gets its full treatment in later modules (referenced in parentheses). Think of this as meeting people at a party before having real conversations with them later.
Don't try to memorize these. Read through once. When you encounter a term in a later module and think "I've seen this before," that's this lesson doing its job.
Interactive animation: The one instruction: do not memorise thirty definitions. Follow the journey.
The 30 Concepts
Interactive animation: The four pairs people mix up - worth more than twenty definitions.
1. Scalability (→ M2, M25)
The ability of a system to handle increased load - more users, more data, more requests - by adding resources. Vertical scaling (bigger machine) is simpler but has limits. Horizontal scaling (more machines) is harder but has no ceiling. Most production systems use both.
Interactive animation: Scale up: one bigger machine. Scale out: more machines behind a load balancer.
2. Availability (→ M2)
The percentage of time a system is operational and serving requests. Measured in "nines" - 99.9% availability (three nines) means ~8.7 hours of downtime per year. 99.99% (four nines) means ~52 minutes. Every additional nine is exponentially harder to achieve.
Interactive animation: Drag across the nines and watch the allowed downtime shrink about ten times with each one.
3. Latency (→ M2, M25)
The time between sending a request and receiving a response. Measured in milliseconds. A user-facing API with 200ms latency feels fast; 2 seconds feels slow. Tail latency (the slowest 1% of requests - p99) matters more than average latency because it represents the worst user experience.
Interactive animation: The average lies. The tail - p99 - is what your slowest users actually feel.
4. Throughput (→ M2, M25)
The number of operations a system handles per unit of time - requests per second, messages per second, bytes per second. Latency is how long ONE request takes; throughput is how many requests the system handles simultaneously.
Interactive animation: A highway: latency is one car's trip, throughput is cars per minute, bandwidth is the lanes.
5. Load Balancer (→ M10)
A component that distributes incoming traffic across multiple servers so no single server is overwhelmed. Sits between clients and servers. Algorithms include round-robin (take turns), least connections (send to the least busy), and consistent hashing (same client always goes to the same server).
Interactive animation: One address in front, a pool of servers behind it, and no single server overwhelmed.
6. Cache (→ M11-M12)
A fast storage layer (usually in memory) that stores copies of frequently accessed data so you don't have to fetch it from the slower primary source (usually a database) every time. Redis and Memcached are the most common caches. Caching is the single biggest performance lever in most systems.
Interactive animation: Check the cache, load from the database on a miss, fill the cache - and invalidate it on a write.
7. CDN - Content Delivery Network (→ M11)
A network of servers distributed globally that cache and serve content (images, videos, static files) from locations close to the user. When a user in Tokyo requests an image, the CDN serves it from a server in Tokyo, not from your origin server in Virginia. Reduces latency and load on your servers.
Interactive animation: Edge, shield, origin: requests are answered close to the user and thin out before your servers.
8. Database (→ M13-M22)
A system for storing, organizing, and retrieving structured data. Relational databases (PostgreSQL, MySQL) store data in tables with relationships. NoSQL databases (MongoDB, DynamoDB, Cassandra) store data in other formats (documents, key-value pairs, wide columns) with different trade-offs.
Interactive animation: A SQL query through the engine - parse, plan, optimise, execute - over two related tables.
9. SQL vs NoSQL (→ M13)
Not a simple binary. SQL databases provide strong consistency, ACID transactions, and flexible queries. NoSQL databases provide horizontal scalability, schema flexibility, and optimized read/write patterns. The choice depends on the workload - not on a philosophical preference.
Interactive animation: Not a binary: five real dimensions decide the database, not a preference.
10. Indexing (→ M14)
A data structure that makes database lookups faster - like the index at the back of a textbook. Without an index, the database scans every row (slow). With an index, it jumps to the right rows (fast). The trade-off: indexes speed up reads but slow down writes (the index must be updated on every insert).
Interactive animation: An index is a balanced tree: root, ranges, leaves - a few hops instead of scanning every row.
11. Replication (→ M28)
Copying data across multiple servers so that if one server dies, the others have the data. Leader-follower replication: one server handles writes (leader), others copy from it (followers) and handle reads. Trade-off: replication adds durability but introduces the problem of consistency - the copies might be briefly out of date.
Interactive animation: One primary takes the writes and streams its log to replicas that serve reads - and can take over.
12. Partitioning / Sharding (→ M29)
Splitting data across multiple machines so no single machine holds everything. A database with 10 TB of data sharded across 10 machines has 1 TB per machine - each machine handles a fraction of the queries. The hard part: deciding how to split (by user ID? by geography? by hash?) and handling queries that span multiple shards.
Interactive animation: A router sends each key to one shard - and the routing strategy decides whether one shard runs hot.
13. Consistent Hashing (→ M2, M29)
A technique for distributing data across machines so that adding or removing a machine moves only a small fraction of the data, not all of it. Used by DynamoDB, Cassandra, and most distributed caches. Without it, every machine change would require reshuffling all data.
Interactive animation: Add or remove a server on the ring and only the keys in one arc move - not the whole keyspace.
14. CAP Theorem (→ M2, M30)
In a distributed system, you can have at most two of three properties: Consistency (every read returns the most recent write), Availability (every request gets a response), and Partition tolerance (the system works despite network failures). Since network partitions are inevitable, the real choice is between consistency and availability during a partition.
Interactive animation: When the network partitions, choose: stay consistent and refuse, or stay available and risk stale reads.
15. Consistency Models (→ M2, M30)
The guarantees a system makes about what you read after a write. Strong consistency: you always read the latest write. Eventual consistency: you'll read the latest write eventually, but maybe not immediately. Causal consistency: you see writes in an order that respects cause and effect. Different systems choose different models.
Interactive animation: From strong to eventual: what a read is allowed to return after a write.
16. API - Application Programming Interface (→ M5)
The contract that defines how two systems communicate. REST, GraphQL, and gRPC are the three dominant API styles. A well-designed API is the most important interface in a system - it determines what clients can do and how they do it.
Interactive animation: An API is a menu: what you can ask for, what you must send, what comes back, what can go wrong.
17. REST (→ M5)
An API style based on HTTP methods (GET, POST, PUT, DELETE) operating on resources identified by URLs. /users/42 is a resource; GET /users/42 retrieves it; DELETE /users/42 removes it. The most common API style on the web.
Interactive animation: Resources and HTTP methods: send each request and watch the status code come back.
18. Message Queue (→ M9, M33)
A system that accepts messages from producers, stores them temporarily, and delivers them to consumers. Decouples producers from consumers - the producer doesn't wait for the consumer to process. RabbitMQ and AWS SQS are common examples. Used for async processing, task dispatch, and load buffering.
Interactive animation: A queue between producer and consumer: each message goes to one consumer, at the consumer's pace.
19. Event Streaming (→ M33)
A system where events are written to a persistent, ordered log and consumed by one or more consumers. Unlike a queue (where a consumed message is deleted), a stream retains events for replay. Apache Kafka is the dominant example. Used for event-driven architectures, real-time analytics, and data pipelines.
Interactive animation: Producers append events to a partitioned log, and consumers read it at their own pace.
20. Microservices (→ M36-M37)
An architecture where a system is split into small, independently deployable services, each responsible for one business capability. The opposite of a monolith (one big application). Microservices enable independent scaling and deployment but add complexity (networking, coordination, observability).
Interactive animation: Modules leave the monolith one at a time, each becoming its own service with its own database.
21. Container (→ M39)
A lightweight, isolated environment for running an application - packages the code and all its dependencies (runtime, libraries) into a portable unit. Docker is the tool; Kubernetes is the orchestrator that manages containers at scale. Containers are how most production services are deployed in 2026.
Interactive animation: A Dockerfile becomes image layers, and the image runs the same way everywhere as a container.
22. Serverless (→ M38)
A compute model where you upload a function and the cloud provider runs it on demand - no servers to manage, no capacity to plan. AWS Lambda is the dominant example. You pay per invocation, not per hour. Great for event-driven and variable traffic; expensive for sustained high load.
Interactive animation: An event triggers a function: idle costs nothing, bursts scale out, and a cold start adds a one-time delay.
23. Rate Limiting (→ M6, M42)
Restricting how many requests a client can send in a given time window - "100 requests per second per API key." Protects your system from misbehaving clients, DDoS attacks, and accidental overload. Token bucket is the most common algorithm.
Interactive animation: Requests inside the budget pass; the rest get a 429 at the limiter and never reach the service.
24. Circuit Breaker (→ M42)
A pattern that detects when a downstream service is failing and stops sending requests to it - "fast fail" instead of waiting for timeouts. Named after the electrical metaphor. Three states: Closed (normal), Open (blocking), Half-Open (testing recovery).
Interactive animation: After repeated failures the breaker opens and fails fast, then lets one probe through to test recovery.
25. Idempotency (→ M5, M42)
An operation is idempotent if performing it multiple times produces the same result as performing it once. Critical for safe retries - if a network timeout occurs, the client retries, and the operation must not produce duplicates (double charges, double orders).
Interactive animation: An Idempotency-Key turns a retried payment into a lookup, so the card is charged once.
26. DNS - Domain Name System (→ M4)
The internet's phone book. Translates human-readable names (www.google.com) into IP addresses (142.250.80.4). Every web request starts with a DNS lookup. DNS also enables load balancing and geographic routing.
Interactive animation: A resolver walks root, TLD and authoritative servers - or answers straight from its cache.
27. Authentication vs Authorization (→ M7)
Authentication answers "who are you?" (login, credentials, identity). Authorization answers "what are you allowed to do?" (permissions, roles, access control). Both are needed; they're different problems with different solutions.
Interactive animation: Two gates: first who you are, then what you are allowed to do.
28. WebSocket (→ M8)
A protocol for full-duplex (bidirectional), persistent connections between a client and server. Unlike HTTP (request-response), a WebSocket connection stays open - the server can push data to the client at any time. Used for chat, live dashboards, collaborative editing, and real-time games.
Interactive animation: One HTTP upgrade, then a single connection where either side can send at any time.
29. Bloom Filter (→ M35)
A probabilistic data structure that answers "is this element in the set?" with either "definitely no" or "probably yes." Uses almost no memory compared to storing the full set. Used to avoid unnecessary database lookups - check the Bloom filter first; if it says "no," skip the query.
Interactive animation: k hashes set k bits: "definitely not in the set", or only "possibly in it".
30. SLO - Service Level Objective (→ M43)
A target for a service's reliability - "99.9% of requests complete in under 300ms." SLOs define the line between "healthy" and "needs attention." Related: SLI (the metric being measured) and SLA (a contractual commitment with financial penalties). The Google SRE framework that modern operations teams use.
Interactive animation: An SLO draws the line between healthy and needs attention - the target every alert is measured against.
The Roadmap Beneath the Vocabulary
Interactive animation: You are not behind: caching gets two modules, databases get six, consensus a whole one.
These 30 concepts aren't random. They map to the course structure:
| Concepts | Course section |
|---|---|
| 1-4 (Scalability, Availability, Latency, Throughput) | Foundations (Phase 1) |
| 5-7 (Load Balancer, Cache, CDN) | Caching & Communication (Phase 2-3) |
| 8-12 (Database, SQL/NoSQL, Index, Replication, Sharding) | Databases (Phase 4) |
| 13-15 (Consistent Hashing, CAP, Consistency Models) | Distributed Systems (Phase 7) |
| 16-17 (API, REST) | APIs (Phase 2) |
| 18-19 (Queue, Streaming) | Data Infrastructure (Phase 8) |
| 20-22 (Microservices, Container, Serverless) | Architecture & Compute (Phase 10-11) |
| 23-26 (Rate Limiting, Circuit Breaker, Idempotency, DNS) | Operational (Phase 2, 13) |
| 27-28 (Auth, WebSocket) | Security & Real-Time (Phase 2) |
| 29-30 (Bloom Filter, SLO) | Data Structures & Observability (Phase 9, 13) |
Every concept you just met will become a full module - or a full section - later. You now have the vocabulary to recognize them when they appear.
Module 1 Complete
You've finished the orientation. You know what this course is, how it's structured, where the community lives, what system design means as an activity, and the 30 concepts you'll encounter throughout. The map is in your hands.
Module 2 begins the technical content: Core Concepts - scalability, availability, reliability, latency, throughput, consistent hashing, the CAP theorem, and consistency models. The vocabulary from this lesson gets its first real treatment.
— Brandon