Glossary

174 terms from System Design Basics in Rust, in plain words, each with the chapter that teaches it.

Search the glossary

#

#[allow(dead_code)]: A Rust attribute that stops the compiler from warning about functions or other items that a program never calls. It is useful in front of a `mod` declaration when a program uses only some of the module's functions.
#[cfg(test)] / #[test]: `#[test]` marks a function as a test, and `#[cfg(test)]` makes a block of code compile only when tests are built. Together they keep test code, such as a TTL cache test with a fake clock, out of the normal program.

A

ACID (atomicity, consistency, isolation, durability): The four promises a database makes about transactions. All of a transaction happens or none of it, rules still hold, transactions running at once don't see each other's half-done work, and committed changes survive a crash.
Alerts: Messages sent to a person when a metric crosses a line, such as an error rate above 1% for 5 minutes.
Amazon S3: The best-known object storage service, where Kettle & Crane's product photos would live before the CDN copies them.
Amazon SQS: A managed message broker from Amazon that stores a queue of messages for workers.
API (Application Programming Interface): The set of requests a program accepts from other programs, such as Kettle & Crane's api.kettleandcrane.com. Each request is a method and path with defined replies.
API key: A long secret string a caller sends, usually in a header, to prove who it is.
Asynchronous work: Work done a moment later by something else, so the customer's request doesn't wait. Saving the order is synchronous, but sending the confirmation email can be asynchronous.
At-least-once delivery: A promise most message brokers make: every message arrives, but sometimes twice. Consumers must therefore cope with duplicates.
Atomic operation: A single step that cannot be split, so nothing can happen between the check and the change. Checking and subtracting stock under one lock keeps two checkouts from selling the last bag.
Authentication: Proving who the caller is, for example with a token.
Authorization: Deciding what an already-identified caller may do. A customer may read their own orders, but only staff may read everyone's.
Auto-increment ID: A number the database hands out in order (1, 2, 3...) for each new row. The shortener turns it into a short code.
Autoscaling: Automatically adding servers when load rises and removing them when it falls, by a rule such as keeping average CPU under 60%.
Availability: The share of time a system answers, written as a percentage such as 99.9%.
Axum: A Rust crate for building web APIs. Real services often add it, along with crates such as Tokio, on top of what the standard library provides.

B

Back pressure: Pushing back on producers when a queue is full so it doesn't grow until memory runs out. A bounded Rust channel makes `send` wait or `try_send` fail.
Back-of-the-envelope estimate: A rough calculation, such as requests per second or storage, aiming for the right order of magnitude. It stops you building something far bigger than you need.
Backups: Copies of data kept elsewhere so it can be restored after a disaster. A backup is only trustworthy once you have tested it by restoring from it.
Base62: Writing numbers with 62 symbols (0-9, a-z, A-Z) instead of 10 so they stay short. The shortener uses it to turn an ID into a short code.
Batching: Grouping many writes into one, such as one commit after many inserts. It waits for the slow disk once instead of many times.
Broker: The program that stores a message queue between producers and consumers, such as RabbitMQ or Amazon SQS.

C

Cache: A small, fast store holding copies of data that is slow to fetch, such as a product page read thousands of times between price changes.
Cache hit / miss: A hit means the data was found in the cache and a miss means it wasn't, so you fetch it from the slow source. The hit ratio is hits divided by all lookups.
Cache invalidation: Removing or updating a cached copy when the data changes, such as writing the new price to the database and then deleting the cached key.
Cache stampede: What happens when a hot key expires and all requests miss at once, flooding the database. Letting one request reload while others wait avoids it.
Cache-aside: A pattern where the app checks the cache first, and on a miss reads the database and stores the result in the cache.
Cache-Control header: An HTTP header telling browsers and CDNs how long to keep a file. `max-age=86400` means keep it for a day.
CAP theorem: The rule that during a network partition a system must choose consistency (refuse rather than be wrong) or availability (answer, maybe stale). Partitions can't be ruled out.
Cassandra: A wide-column NoSQL database for huge tables spread over many machines, such as billions of events.
CDN (content delivery network): Servers in many cities that hold copies of files such as product photos, so a customer gets them from nearby instead of from Portland.
Celebrity problem: When one very popular source has so many followers that fan-out on write means huge numbers of writes per post, and the last followers see it late. Hybrid fan-out is the usual fix.
Circuit breaker: A guard that notices repeated failures of another service and stops calling it for a while. It is closed while calls pass, open after too many failures in a row, and half-open once a trial call is allowed.
Client / server: A client is a program, like a browser, that asks for something, and a server is a program that listens and answers.
Clock (injected clock): A function returning the current time in seconds, passed into the cache so tests can swap in a fake clock they move by hand. The real clock uses `Instant`, which never jumps backward.
Commit: The step that saves a transaction's changes for good. A database commit waits until the data is safely on disk, which is slow, so one commit for many inserts is faster.
Component: One part of a system, such as a web server, database, cache or queue.
Consensus: The process of getting several servers to agree on something, such as which one is the new primary. It is needed for failover and other decisions that must be the same on every server.
Consistency: Whether all readers see the latest data. Strong consistency means every read sees the latest write, eventual consistency means copies catch up over time, and the 'C' in ACID means database rules such as "quantity is never negative" still hold.
Consistent hashing: A sharding method that moves only a fraction of keys when shards are added, instead of most of them as `% shard_count` does.
Content-Type / Content-Length: HTTP headers saying what kind of data the body holds (such as application/json) and how many bytes it has.
CRC-32: A checksum that turns bytes into a whole number. It's stable, so the same key always gives the same number, which makes it suitable for hash sharding.
Cross-shard query: A question that doesn't include the shard key, so it must ask every shard and combine the answers, like 'best sellers this week'.

D

Dead-letter queue: A queue where messages go after failing too many times, so a person such as Priya can look at them instead of the message retrying forever.
Denormalization: Storing a copy of data in the shape a page needs, even though it repeats data held elsewhere. It trades some staleness and storage for fast reads.
Design document: A short shared description of what you'll build and why, which the team reviews before anyone writes code.
DNS (Domain Name System): The internet's phone book, which turns a name like shop.kettleandcrane.com into an IP address.
Document store: A NoSQL database holding JSON-like documents, good for products with varied fields. MongoDB is an example.
Downtime: The time a system is not answering. Each extra nine of availability cuts it by ten.
Durability: Saved data is never lost. Once an order is confirmed it survives crashes.
DynamoDB: A key-value store from Amazon, suited to sessions and carts.

E

Edge location: A CDN server in one of many cities that keeps copies of files near customers.
Endpoint: One method and path pair an API accepts, such as `GET /v1/products`.
Error rate: The share of requests that fail, a typical metric to watch and alert on.
Eventual consistency: Reads may be briefly out of date, but once writes stop every copy catches up, as with read replicas. It lets any copy answer, so it is faster and more available.
Eviction: Throwing entries out of a full cache to make room.
Exponential backoff: Doubling the wait after each failed retry (0.1 s, 0.2 s, 0.4 s...), giving a struggling server room to recover.

F

Failover: Switching to a standby when the main part fails, such as promoting a replica to primary or a spare load balancer taking over an address.
Fallback: A simpler answer shown when a part fails, such as a cached 'Popular this week' list when recommendations are down.
Fan-out: Copying one post or message to many readers, such as a café's post going to all its followers' feeds.
Fan-out on write / read: Fan-out on write copies a post into every follower's feed when it's posted, which makes reads fast. Fan-out on read stores posts once and gathers them when a customer opens the feed, which makes posting cheap.
Feed: A list of recent posts from the cafés a customer follows, newest first.
Functional requirement: What the system does, such as 'customers can check out' or 'Priya can look up an order by its ID'.

G

Graceful degradation: Offering less instead of nothing when a part fails, such as showing a cached list or letting emails wait on the queue.

H

HAProxy: A load balancer you run yourself, along with nginx.
Hash sharding: Choosing a shard by turning the key into a number with a stable hash and taking the remainder after dividing by the shard count.
Header: A `Name: value` line in an HTTP request or response that carries extra information, such as `Content-Type`, `Authorization` or `Idempotency-Key`.
Health check: A regular test, such as asking `GET /v1/health` for a 200, that a server is answering. A failing server is marked down until it passes again.
Horizontal scaling: Adding more machines to share the work. It has no ceiling, but the data must be split between them.
Hot key: A single key, such as a café with hundreds of orders a week, that makes its shard busier than the rest.
Hot spot: A shard or key that gets far more traffic than the others, as with range sharding by date where all new orders hit the newest shard.
HTTP (Hypertext Transfer Protocol): The plain-text protocol browsers and servers speak: a request with a method, path, headers and maybe a body goes out, and a response with a status code comes back.
HTTP method: The verb of a request. `GET` reads, `POST` creates, `PUT` replaces and `DELETE` removes.
HTTP status codes: The number that starts an HTTP response: 2xx means success, 4xx the client's mistake and 5xx the server's problem. Common codes are 200 OK, 201 Created, 301 moved for good, 302 moved for now, 400 bad request, 401 caller unknown (missing or wrong token), 403 known but not allowed, 404 not found, 409 conflict with the current state, 429 too many requests, 500 server error and 503 service unavailable.
HTTPS: HTTP encrypted with TLS so nobody in between can read things like card numbers or tokens.
Hybrid fan-out: Fan out on write for ordinary cafés, but fetch the few very popular cafés' posts at read time and merge them in. It fixes the celebrity problem.

I

Idempotency key: A unique ID the app sends with a request, in an `Idempotency-Key` header, so the server can return the first result for a retry instead of, say, charging twice.
Idempotent: Sending a request twice has the same effect as sending it once. `GET`, `PUT` and `DELETE` are, but a plain `POST` that creates an order is not.
Idempotent consumer: A queue worker that records which messages it has handled and skips repeats, so a duplicate delivery doesn't send a second email.
Index: A sorted list of one column's values pointing at their rows, so the database can jump to them instead of scanning every row. It speeds reads but slightly slows writes.
IP address: A number such as 203.0.113.7 that identifies a machine on the network.

J

Jitter: Randomness added to retry waits so a thousand clients don't all retry at the same instant.
JSON: A text format for data, like `{"name": "Speckled blue mug", "price": 18}`, used for API request and response bodies.

K

Kafka: A popular message broker built around topics and used for event streaming, covered in the next book.
Key-value store: A NoSQL database holding one value per key, like a `HashMap`. It suits sessions and carts, and Redis and DynamoDB are examples.

L

Latency: How long one request takes, measured in units such as milliseconds.
Layer 4 / Layer 7: A Layer 4 balancer looks only at addresses and ports and passes bytes on unread, so it's very fast. A Layer 7 balancer reads the HTTP request, so it can route by path and handle HTTPS.
Lcg (linear congruential generator): A tiny random-number generator that scrambles a number with a multiply and an add each time it is called, useful when the standard library has no random numbers. Starting from a fixed seed makes the 'random' sequence, such as retry waits, repeat identically on every run.
Least connections: A balancing rule that sends each request to the server with the fewest requests still open. It copes better than round robin when requests differ in cost.
Load balancer: A server in front of the app servers that takes every request and passes it to one of them. Customers only see its address.
Logs: Records of events, such as each failed charge, used to see what happened.
LRU (least recently used): An eviction rule that throws out the entry that has gone unread the longest when the cache is full.

M

Memcached: A shared cache server, like Redis, that several app servers can use.
Message queue: A line of messages held by a broker between producers and consumers, so slow work like emails happens later without delaying the reply. The prototype's order queue is called an outbox.
Metrics: Numbers tracked over time, such as the error rate or p99 latency.
Microservices: A design that splits a system into many small programs that talk to each other over APIs. It contrasts with a monolith, which keeps everything in one program.
mod / pub: In Rust, `mod name;` loads `name.rs` from the same folder as a module, and `pub` makes a function in it visible outside the module. Together they let several files share code.
MongoDB: A document store database for JSON-like documents.
Monitoring: Watching what's happening in a running system through logs, metrics and alerts.
Monolith: One program that does everything, holding all of a system's features in a single application. It is simpler to build and run than splitting the system into microservices, and it can still use a few helper components.
mpsc channel: Rust's standard queue between threads, with a sending end and a receiving end. `sync_channel(n)` limits it to n messages, and `try_send` fails at once if it's full.
MySQL: A relational database, like PostgreSQL.

N

Network partition: A failure where some servers can't reach others, such as replicas losing contact with the primary.
nginx: A common load balancer that you run yourself.
Nines: A way of describing availability by the number of 9s, so 99.9% is 'three nines'. Each extra nine cuts downtime by ten and costs much more.
Non-functional requirement: How well the system does its job: latency, availability, durability and scalability.
NoSQL: Databases that aren't relational tables, such as key-value stores. They give up some features for simple, very large scale.

O

Object storage: A service that stores any number of files by name, cheaply and durably, such as Amazon S3. A CDN fetches photos from it.
Order of magnitude: The rough size of a number as a power of ten, such as whether traffic is 2, 200 or 20,000 requests a second. Estimates aim for it.

P

p99 (percentile): The time that 99% of requests beat, so the slowest 1% take longer. An average of 80 ms can hide a p99 of 3 seconds.
Pagination: Sending a long list one page at a time, with `?page=2` or `?after=K-1040`.
Peak factor: How many times the average load the busiest moment reaches. The shop's holiday sale hour is about 10 times the average.
Polling: A client asking again and again whether anything is new. It's simple, but slow to notice news and wasteful when nothing has changed.
Port: A numbered door on a machine that lets different network programs share one IP address. For example, 443 is used for secure web traffic, and a test server might use 8121.
PostgreSQL: A relational database whose transactions would do the all-or-nothing work for a real shop.
Precompute: Calculating a heavy result ahead of time and storing it for fast reads, like a job saving the top ten best sellers every 10 minutes.
Presence: Whether a user is online. The chat design tracks it with a TTL key that expires if the app stops saying 'I'm here'.
Primary: The database copy that takes every write and sends changes to the read replicas.
Producer / consumer: A producer puts messages on a queue, like checkout adding an order ID. A consumer, or worker, takes them off and does the work, like sending the email.
Pub/sub (publish/subscribe): One message is published to a topic and a copy goes to every subscriber, such as the email, shipping and sales-report services all hearing 'order placed'.

R

Race condition: A bug where the result depends on how two operations overlap in time, such as two checkouts both reading 1 bag and both selling it.
Range sharding: Giving each shard a range of keys, such as January to March on shard 0. Range queries hit one shard, but new data can create a hot spot.
Rate limiting: Capping how many requests each client may make in a given time. It protects a service from being overloaded by a single caller, such as a script hammering an API.
Read replica: A copy of the database that receives changes from the primary and answers reads, so several servers share the read load.
Read-heavy / write-heavy: A read-heavy system is read far more often than it's changed, like the shop at about 100 reads per write. A write-heavy one, such as click logging, is the reverse, and the ratio tells you which side to scale first.
Read-your-writes: A promise that users always see their own latest changes. It can be done by reading their data from the primary for a short time after they write.
Read/write router: App code that sends writes to the primary database and reads to the replicas, taking the replicas in turn.
Redirect: A response, with status 301 or 302 and a `Location` header, that tells the browser to go to another URL.
Redis: A key-value store often used as a shared cache server.
Redundancy: Having two or more of each important part, so one failure doesn't stop everything.
Relational database: A database of tables with fixed columns, queried with SQL, where tables can be combined in one query (a join). It's the right start for orders and stock.
Replication: Keeping copies of a database on several servers.
Replication lag: The delay before a replica has a change made on the primary, so a read just after a write can show the old value.
Requirement: Something the system must do or be, either functional or non-functional.
Resharding: Moving rows to new shards when you add shards. With `% shard_count`, most keys move, which is costly.
Resource: The thing a REST URL names, always a noun such as `orders`. The HTTP method says what to do with it.
REST: A common API style where URLs name resources as nouns, like `/v1/orders`, and the HTTP method says what to do with them.
Retry: Trying a failed call again, which helps with brief failures. Retry only idempotent work, with backoff and jitter.
Rollback: Undoing a transaction's changes when any step fails, as when the prototype puts the stock backup back.
Round robin: A balancing rule that gives requests to servers in turn, skipping any marked down.
RPS (requests per second): How many requests arrive each second. Average RPS is daily requests divided by 86,400, and peak RPS is that times the peak factor.
rustc --test: Compiles a Rust file as a test program that runs its `#[test]` functions.
rustc -O: The command that compiles a Rust file, with `-O` turning optimizations on. `./file` then runs it.

S

Scalability: The ability to keep working as the load grows.
Scan: The database reads every row of a table to answer a query, which is slow on big tables. An index lets it search instead.
Session: What a server knows about one visitor, such as who is logged in and what's in their cart.
Shard key: The column whose value decides which shard a row lives on, such as `customer_id` for orders.
Sharding: Splitting one table's rows across several databases, each piece being a shard. It costs extra work for hot keys, cross-shard queries and resharding, so shard only when you must.
Short code: The few symbols after the slash in a short link, such as `abc12` in `go.kettleandcrane.com/abc12`.
SLO (service level objective): A team's target for a service, such as 'checkout is available 99.9% of the time'.
SPOF (single point of failure): One part whose failure stops everything, such as a lone database. Redundancy removes it.
Stable hash: A hash function that gives the same number for the same key on every machine and every run. Rust's `HashMap` hasher is randomly seeded, so it isn't stable and would move customers between shards after a restart.
Stale: Cached or copied data that no longer matches the source, such as an old price in the cache.
Stateless server: A server that keeps no session data in its own memory, so any server can answer any request and adding servers is easy.
Sticky session: A load balancer sending a customer to the same server every time because that server holds their cart in memory. If it dies, the cart is lost.
Strong consistency: Every read sees the latest write, as when reading from the primary.
System design: Deciding a system's parts and how they talk to each other, before or while you build it. It usually starts as a whiteboard sketch of boxes and arrows.

T

TCP: The connection protocol that delivers bytes in order and resends lost ones. HTTP runs on top of it.
TcpListener / TcpStream: Rust standard-library types for networking. `TcpListener::bind` claims a port and hands out a `TcpStream`, a two-way pipe of bytes, for each client.
Time units (ms, µs, ns): A millisecond is a thousandth of a second, a microsecond a millionth and a nanosecond a billionth. Memory reads take about 100 ns, SSD reads 0.1 ms and a trip across the country about 70 ms.
Timeout: The longest you'll wait for a reply to a network call. Every call needs one, or a hung server ties up your threads.
TLS: The encryption that HTTPS uses so nobody between client and server can read the traffic.
Token: A long secret string sent in a header, such as `Authorization: Bearer <token>`, to prove who the caller is.
Tokio: A Rust crate for async networking that real services use instead of the standard library alone.
Transaction: A group of steps that succeed or fail together: committed if all finish, rolled back if any fails. An order should reserve every cart line or none.
TTL (time to live): How long a cached entry stays valid. After that it expires, so the next lookup misses and fetches a fresh copy.

U

URL shortener: A service that turns long addresses into short links and redirects visitors from the short one to the long one.

V

Versioning: Putting a version such as `/v1/` in API paths, so a `/v2/` can appear while old apps keep using `/v1/`.
Vertical scaling: Moving to a bigger machine. It's simple, but there's a largest machine you can buy.

W

WebSocket: A connection that starts as an HTTP request and then stays open, so either side can send a message at any time. The chat server uses one per person to push messages.
Weighted round robin: Round robin where bigger servers appear more often in the rotation and so get more requests.
Wide-column store: A NoSQL database with huge tables spread over many machines, suited to billions of events. Cassandra is an example.
Write-through cache: A cache that is written together with the database at the same time, instead of being invalidated afterwards.