System Design Glossary

A

ACID

Category: databases and storage.

ACID is the set of guarantees a database transaction gives: Atomicity (all of the writes happen or none do), Consistency (the data moves from one valid state to another), Isolation (concurrent transactions do not see each other's half-finished work) and Durability (once committed, the data survives a crash). Relational databases such as PostgreSQL and MySQL are built around it.

Say "ACID" when a question involves money, inventory, bookings or anything where a half-applied write is unacceptable. Be precise about which letter you need: most payment flows need atomicity and durability on one machine; isolation levels are a separate conversation. See also "Isolation levels", "BASE" and "Distributed transactions".

Active-active and active-passive

Category: availability and reliability.

Two ways to run redundant copies of a component or a whole site. Active-passive keeps a standby that takes over only when the primary fails. Active-active serves traffic from all copies at the same time, which uses the hardware fully but means writes may happen in several places at once.

Active-passive is the simpler answer for a database or a load balancer pair; active-active is the usual answer for stateless services and for multi-region setups where users must be served near home. If you choose active-active for a database, be ready to explain conflict resolution. See also "Failover" and "Multi-region architecture".

Adaptive bitrate streaming (HLS, DASH)

Category: media and content delivery.

A way of delivering video in which the file is transcoded into several quality levels, cut into short segments (typically 2 to 10 seconds) and described by a manifest. The player downloads the segments over plain HTTP and switches quality as the network allows. HLS (Apple) and MPEG-DASH are the two common formats.

The expected answer for the video-serving part of a YouTube or Netflix design: upload, transcode asynchronously into a ladder of resolutions, store segments in object storage, serve through a CDN. Mention that transcoding is CPU-heavy and belongs in a queue-driven pipeline, not in the request path.

API gateway

Category: networking and communication.

A single entry point in front of a set of backend services. It routes requests to the right service and handles cross-cutting concerns such as authentication, rate limiting, request logging, TLS termination and sometimes response aggregation. Examples: Amazon API Gateway, Kong, Apigee, NGINX used as a gateway.

Draw it between the clients and your services whenever you have more than one service or need rate limiting and auth in one place. Make clear how it differs from a load balancer (it understands the API, not just connections) and note that it is itself a component that must be scaled and made redundant. See also "Load balancer" and "Reverse proxy".

Asynchronous processing

Category: architecture patterns.

Doing work outside the request-response path: the server accepts the request, puts a job on a queue, replies immediately, and workers finish the job later. Sending e-mails, resizing images, generating reports and updating search indexes are typical examples.

One of the most useful moves in any design. Whenever a step is slow, unreliable or not needed for the user's immediate answer, say "I would do this asynchronously through a queue" and explain how the user learns the result (polling a status endpoint, a push notification, a WebSocket message). Name the trade-off: eventual completion and the need for idempotent workers. See also "Message queue" and "Idempotency".

Authentication and authorization (sessions, JWT, OAuth)

Category: security.

Authentication establishes who the caller is; authorization decides what they may do. The two common mechanisms are server-side sessions (the server stores session state and the client holds a session ID in a cookie) and signed tokens such as JWT, where the token itself carries the claims and the server only verifies the signature. OAuth 2.0 and OpenID Connect are the standard protocols for delegated login ("sign in with Google").

Usually a one-minute topic unless the question is about auth itself. Say where it happens (the API gateway or a dedicated auth service), and name the JWT trade-off: no database lookup per request, but revocation is hard, so keep tokens short-lived and use refresh tokens. Store passwords only as salted hashes (bcrypt, scrypt or Argon2).

Autoscaling

Category: scalability.

Adding or removing instances of a service automatically based on a signal such as CPU load, request rate, queue length or a schedule. Cloud platforms and Kubernetes provide it for stateless workloads.

Mention it for stateless tiers (web servers, workers) and say which metric drives it; queue length is the right signal for workers, request rate or CPU for web servers. Note the limits: new instances take seconds to minutes to come up, so sudden spikes still need headroom, rate limiting or load shedding, and databases do not autoscale the same way. See also "Stateless vs. stateful services".

Availability (the "nines")

Category: availability and reliability.

The fraction of time a system is able to serve requests, usually written as a percentage. Each extra nine cuts the allowed downtime by ten: 99% allows about 3.65 days of downtime a year, 99.9% about 8.8 hours, 99.99% about 53 minutes and 99.999% about 5 minutes. Availability of a chain of components is the product of their individual availabilities, so adding dependencies lowers it; redundant parallel components raise it.

Ask for the target early, because it drives the design: 99.9% is reachable with a single region and a good failover plan, 99.99% and above needs redundancy at every layer and usually several regions. Never promise "100%". See also "SLA, SLO and SLI" and "Single point of failure".

Availability zones and regions

Category: availability and reliability.

Cloud providers group their data centres into regions (a geographic area such as Frankfurt or Virginia) made of several availability zones (physically separate data centres with independent power and networking, connected by fast links). A failure of one zone should not take down the others.

The standard baseline is "deployed across at least two or three zones in one region": replicas of the database and the cache in different zones, stateless services spread across all of them, a load balancer in front. Going multi-region is a bigger step with its own data problems. See also "Multi-region architecture".

B

Back-of-the-envelope estimation

Category: interview method.

Rough arithmetic, done out loud, that turns the requirements into numbers: daily and peak requests per second, storage per year, bandwidth, cache size. The goal is the right order of magnitude, not precision.

Expected in the first five to ten minutes. Work from stated assumptions ("10 million daily active users, each posts twice a day"), convert per day to per second by dividing by about 100,000 (a day has 86,400 seconds), assume peak is two to three times average, and round aggressively. Then use the numbers: 500 writes per second fits one database; 50,000 does not and justifies sharding. See the "Numbers Worth Remembering" section below.

Backpressure

Category: availability and reliability.

A mechanism by which a slow consumer signals a fast producer to slow down, instead of letting unbounded work pile up in memory or in queues until something falls over. Bounded buffers, blocking writes, TCP flow control and "429 Too Many Requests" responses are all forms of backpressure.

Bring it up when you draw a queue or a stream between components that run at different speeds. Say what happens when the queue is full: block the producer, drop or reject new work, or shed low-priority work. Unbounded queues are a classic hidden failure. See also "Load shedding" and "Rate limiting".

BASE

Category: databases and storage.

The counterpart of ACID for systems that favour availability: Basically Available (the system answers even during partial failures), Soft state (data may be in flux while replicas catch up) and Eventually consistent (replicas converge given time). Dynamo-style NoSQL stores follow it.

Use it to describe the trade you make when you accept eventual consistency to get availability and scale, for example for likes, view counters or feeds. Do not use it to describe anything involving money without a strong justification. See also "Eventual consistency" and "CAP theorem".

Base62 encoding

Category: data and algorithms.

Representing a number using 62 characters (0-9, a-z, A-Z) so that it is short and safe to put in a URL. Seven base62 characters give 62^7, about 3.5 trillion, distinct values.

The usual building block of the URL shortener question: generate a unique numeric ID (from a counter, a key-generation service or a Snowflake-style generator) and encode it in base62, rather than hashing the long URL and fighting collisions. Mention that sequential IDs make short URLs guessable and how you would deal with that. See also "Unique ID generation".

Batch processing (MapReduce, Spark)

Category: data processing.

Processing a large, bounded set of data in one scheduled job: nightly reports, recomputing recommendations, building search indexes. MapReduce (the 2004 Google paper, later Hadoop) split such work into map and reduce steps across many machines; Apache Spark is the modern, in-memory successor.

The right tool when results can be hours old and the job touches most of the data. Contrast it with stream processing (continuous, seconds of delay) and say how the output gets back into the serving system, usually a bulk load into a key-value store. See also "Stream processing" and "Data warehouse and data lake".

Bloom filter

Category: data and algorithms.

A compact probabilistic structure that answers "is this item possibly in the set?" It can return false positives but never false negatives, and it uses a few bits per item instead of storing the items. Items cannot be removed from a standard Bloom filter.

Use it to avoid expensive lookups: checking whether a username is taken before hitting the database, skipping disk reads for keys an LSM-tree store does not hold, filtering URLs a crawler has already seen, or de-duplicating recommendations already shown. Always state the false-positive rate and what happens on a false positive. See also "HyperLogLog" and "Count-min sketch".

B-tree and LSM tree

Category: databases and storage.

The two main ways storage engines organise data on disk. A B-tree keeps sorted pages and updates them in place; reads are fast and predictable, writes cost random I/O. PostgreSQL, MySQL (InnoDB) and most relational databases use it. A log-structured merge (LSM) tree appends writes to an in-memory table, flushes it as sorted files (SSTables) and merges them in the background (compaction); writes are very fast, reads may check several files. Cassandra, RocksDB, LevelDB and HBase use it.

Mention it when choosing a database for a write-heavy workload (logs, events, time series: LSM) versus a read-heavy, transactional one (B-tree). It shows you know why "NoSQL is faster for writes" is sometimes true. See also "Write-ahead log".

Bulkhead pattern

Category: availability and reliability.

Isolating resources (thread pools, connection pools, instances) per dependency or per customer so that one slow or failing part cannot exhaust everything, named after the watertight compartments of a ship.

Pair it with circuit breakers when discussing how one slow downstream service could take the whole API down. Example: a separate connection pool and timeout for the recommendation service, so that if it hangs, checkout still works. See also "Circuit breaker" and "Graceful degradation".

C

Cache (caching)

Category: caching.

Keeping a copy of data in a faster or closer place so that repeated reads do not go back to the slow source. Caches exist at every layer: the browser, the CDN, a reverse proxy, an in-memory store such as Redis or Memcached in front of the database, and the database's own buffers. The key metric is the hit ratio.

Cache the reads that are frequent and tolerate slight staleness: user profiles, product pages, feeds, computed counts. Always say three things: what you cache (and the key), how long (TTL) or how it is invalidated, and what happens on a miss. Caching is the first answer to "the database is overloaded with reads"; sharding is the answer for writes. See also "Cache invalidation and write policies", "Cache eviction policies" and "Thundering herd".

Cache eviction policies (LRU, LFU, FIFO)

Category: caching.

Rules for which entry to drop when a cache is full. LRU (least recently used) drops what was not touched for the longest time and is the default almost everywhere. LFU (least frequently used) keeps popular items even if briefly untouched. FIFO and random eviction are simple but worse. Redis also offers TTL-based and approximate LRU/LFU modes.

LRU is the safe answer; mention LFU when the access pattern has a stable popular set (top products, celebrity profiles). If asked to implement an LRU cache, the known solution is a hash map plus a doubly linked list, giving O(1) get and put.

Cache invalidation and write policies (cache-aside, write-through, write-back)

Category: caching.

How the cache and the database are kept in step. Cache-aside (lazy loading): the application reads the cache, on a miss reads the database and fills the cache; writes go to the database and delete or update the cache entry. Read-through: the cache itself loads from the database. Write-through: every write goes to the cache and the database synchronously, so the cache is always fresh but writes are slower. Write-back (write-behind): writes go to the cache and are flushed to the database later; fast, but data can be lost if the cache dies. Write-around: writes bypass the cache.

Cache-aside with a TTL is the default for read-heavy data. Choose write-through when stale reads are unacceptable right after a write, write-back only for things such as counters or metrics where a small loss is tolerable. State the staleness window explicitly; "cache invalidation is hard" is only an answer if you follow it with how you bound the staleness.

CAP theorem (and PACELC)

Category: distributed systems.

In a distributed data store, when a network partition separates the nodes, you must choose between Consistency (every read sees the latest write, in the strict, linearizable sense) and Availability (every request gets a non-error answer). Partition tolerance is not optional, because networks do fail. PACELC extends this: even without a partition (Else), there is a trade-off between Latency and Consistency.

Use it as a vocabulary, not a slogan. Say which side a chosen store sits on (a single-leader relational database with synchronous replication leans CP; Cassandra and DynamoDB in their default settings lean AP) and, more usefully, which parts of your system need which. A bank balance needs consistency; a like count can be available and eventually consistent. Do not say "I pick CA".

CDN (content delivery network)

Category: media and content delivery.

A network of servers spread around the world that cache content close to users and serve it with low latency: images, video segments, JavaScript, CSS, downloads and increasingly whole API responses. Requests go to the nearest edge server; on a miss it fetches from the origin and caches the result. Cloudflare, Akamai, Fastly and CloudFront are examples.

Put static and media content on a CDN in almost every design, give it a TTL and a cache key, and say how you invalidate (versioned file names are the easy way). Note the difference between pull CDNs (cache on first request) and push CDNs (you upload ahead of time). CDNs also absorb traffic spikes and DDoS attacks away from the origin. See also "HTTP caching".

Change data capture (CDC)

Category: data processing.

Reading the database's own change log (the binlog in MySQL, the WAL in PostgreSQL) and publishing every insert, update and delete as an event stream. Debezium is the common open-source tool; it typically feeds Kafka.

The clean way to keep a search index, a cache, a data warehouse or another service in sync with the primary database without dual writes from application code. Combine it with the outbox pattern when you need application-level events rather than raw row changes. See also "Outbox pattern" and "Event streaming".

Chaos engineering

Category: availability and reliability.

Deliberately injecting failures (killing instances, adding latency, cutting a zone) in a controlled way to check that the system degrades as designed. Netflix's Chaos Monkey made the practice known.

A short, credible way to close a design: "I would verify the failover path by regularly killing a replica in staging and later in production". Only mention it if you have already described what the failover should do.

Chunking (file storage)

Category: databases and storage.

Splitting a large file into fixed-size or content-defined blocks (Dropbox used 4 MB), storing each block under a hash of its content, and keeping a small metadata record that lists the blocks of each file. Unchanged blocks are shared between versions and between users (deduplication), and syncing a change uploads only the changed blocks.

The core of the Dropbox or Google Drive question. Describe the metadata database (file to block list), the block store (object storage), and how the client detects changes. Mention checksums for integrity and resumable uploads. See also "Object storage" and "Merkle tree".

Circuit breaker

Category: availability and reliability.

A wrapper around calls to a dependency that counts failures and, once a threshold is crossed, "opens" and fails fast for a while instead of waiting on timeouts. After a cool-down it lets a few test requests through (half-open) and closes again if they succeed. Hystrix and resilience4j popularised it.

Use it whenever one service calls another over the network. It prevents a slow dependency from tying up all your threads and gives it time to recover. Say what you return while the breaker is open: a cached value, a default, or a clear error. See also "Bulkhead pattern", "Timeouts" and "Retries".

Clocks and ordering (Lamport timestamps, vector clocks)

Category: distributed systems.

Machines' clocks drift and are only roughly synchronised (NTP typically keeps them within milliseconds, sometimes much worse), so wall-clock time cannot reliably order events across nodes. Lamport timestamps (1978) are counters that give a consistent "happened-before" order; vector clocks (one counter per node) additionally detect that two updates were concurrent and therefore conflict. Hybrid logical clocks combine both with physical time; Google Spanner's TrueTime uses GPS and atomic clocks to bound the uncertainty.

Bring it up when the design has concurrent writes in several places: multi-leader replication, collaborative editing, or "last write wins" conflict resolution, which silently depends on clocks. Saying "timestamps are not safe for ordering across machines" and offering a version or sequence number instead is a senior-level signal. See also "Conflict resolution".

Compression

Category: data and algorithms.

Trading CPU time for smaller data on the wire or on disk. Gzip, Brotli and zstd are general-purpose; columnar formats such as Parquet compress analytics data very well; images and video use their own lossy codecs.

A cheap optimisation to name for bandwidth-heavy flows (API responses, logs, events in Kafka, cold storage). Mention that compression is done once and decompressed many times for static content, so it belongs in the build or upload pipeline.

Conflict resolution (last-write-wins, merge)

Category: distributed systems.

What to do when two replicas accept different writes to the same item before they have synchronised. Options: last-write-wins (LWW, keep the one with the later timestamp, losing the other), keep both versions and let the application or user merge (Dynamo's "siblings"), use data types that merge automatically (CRDTs), or avoid the problem by routing all writes for a key to one leader.

Whenever you say "multi-leader" or "active-active writes", the next sentence must be your conflict strategy. LWW is acceptable for things such as a profile picture, dangerous for counters, carts or documents. See also "CRDT" and "Multi-leader replication".

Connection pooling

Category: databases and storage.

Keeping a set of open database connections and reusing them, because opening a connection is slow and databases handle only a limited number of them (a few hundred to a few thousand). PgBouncer and ProxySQL are stand-alone poolers; most frameworks have one built in.

Mention it when you scale the stateless tier: a hundred web servers each opening a hundred connections would overwhelm the database, so put a pooler in between and size pools deliberately. It also shows up in serverless designs, where thousands of short-lived functions cannot each hold a connection.

Consensus (Raft, Paxos)

Category: distributed systems.

Getting a group of nodes to agree on a value or an ordered log of operations even though some of them may crash or be slow, as long as a majority is alive. Paxos (Leslie Lamport) is the classic algorithm; Raft (2014) was designed to be understandable and is used by etcd, Consul and CockroachDB. ZooKeeper uses a similar protocol called Zab.

You will rarely implement it, but you should know what needs it: leader election, distributed locks, configuration, and strongly consistent replicated databases. The practical advice is to use an existing coordination service rather than build consensus into your own application. Consensus needs a majority, so clusters have an odd number of nodes (3 or 5). See also "Coordination service" and "Quorum".

Consistency models (strong, linearizable, causal, eventual)

Category: distributed systems.

The contract about what a read may return in a replicated system. Linearizable (the strongest usual form of "strong consistency"): every read returns the latest completed write, as if there were one copy. Causal: operations that depend on each other are seen in order, but independent ones may appear in any order. Session guarantees such as read-your-writes (a user sees their own updates) and monotonic reads (a user never sees time go backwards) are weaker, practical promises. Eventual: replicas converge if writes stop, with no promise about the meantime.

Pick the model per feature and name it. "Read-your-writes for the author's own post, eventual for everyone else's feed" is a strong, concrete answer. Stronger models cost latency and availability. See also "Eventual consistency", "Linearizability" and "CAP theorem".

Consistent hashing

Category: scalability.

A way to assign keys to servers so that when a server is added or removed only about 1/N of the keys move, instead of almost all of them as with simple "hash mod N". Keys and servers are placed on a ring by hash; each key belongs to the next server clockwise. Virtual nodes (each server placed many times on the ring) balance the load and let stronger servers take more. Used in Dynamo, Cassandra, Memcached clients and many load balancers.

The standard answer to "how do you distribute keys across cache or database nodes and what happens when you add one?" Draw the ring, mention virtual nodes, and say how replication works (the key is also stored on the next few servers on the ring). See also "Sharding".

Coordination service (ZooKeeper, etcd)

Category: distributed systems.

A small, strongly consistent, highly available store built on a consensus protocol, used for the things that must be agreed on by everyone: leader election, distributed locks, service discovery, configuration and membership. ZooKeeper (from Hadoop, used by Kafka until recently) and etcd (used by Kubernetes) are the common ones.

When your design needs a lock, a leader, or "exactly one worker does this", say you would use a coordination service and explain the mechanism (ephemeral nodes or leases that disappear when the holder dies). Keep the data in it small; it is not a general database. See also "Leader election" and "Distributed lock".

Count-min sketch

Category: data and algorithms.

A probabilistic structure that estimates how many times each item has been seen using a fixed, small amount of memory. It can overestimate (because of hash collisions) but never underestimate.

The usual answer for "top K" or "heavy hitters" questions over a huge stream, such as trending hashtags, most-viewed videos or rate limiting over millions of keys, when exact counting would not fit in memory. Combine it with a small heap of the current top K. See also "Bloom filter" and "HyperLogLog".

CQRS (command query responsibility segregation)

Category: architecture patterns.

Separating the write model (commands that change state) from the read model (queries), often with different data stores: writes go to a normalised transactional store, reads come from denormalised views built for each screen. The read side is updated through events.

Use it when reads and writes have very different shapes or volumes, such as an order system that is written once but queried in dozens of ways. It pairs naturally with event sourcing and materialized views. The cost is eventual consistency between the two sides and more moving parts, so do not propose it for a simple CRUD application. See also "Event sourcing" and "Materialized view".

CRDT (conflict-free replicated data type)

Category: distributed systems.

A data structure designed so that replicas can be updated independently and merged automatically, always arriving at the same result regardless of the order in which updates arrive. Examples: a grow-only counter, a set where adds win over removes, and sequence types used for collaborative text editing. Figma, Apple Notes and Redis Enterprise use them; Google Docs uses the related operational transformation (OT) approach.

The answer for collaborative editing, offline-first mobile apps and distributed counters where you cannot route all writes through one leader. Mention that CRDTs trade some semantics (you get "a" consistent merge, not necessarily the one a human would choose) and metadata overhead. See also "Conflict resolution".

D

Database index

Category: databases and storage.

A separate structure (usually a B-tree, sometimes a hash) that lets the database find rows by a column's value without scanning the whole table. Composite indexes cover several columns in order; a covering index contains every column a query needs so the table is never touched. Every index slows down writes, because it must be updated too.

When you present a data model, say which columns are indexed and tie each index to a query ("lookups by user_id and created_at for the timeline"). Explain that a query that filters on an unindexed column over a large table is a full scan and will be the bottleneck. See also "B-tree and LSM tree" and "Inverted index".

Data warehouse and data lake

Category: data processing.

A data warehouse is a database optimised for analytical queries over huge volumes (column storage, compression, parallel scans): Snowflake, BigQuery, Amazon Redshift. A data lake is cheap object storage holding raw files (often Parquet) that several engines can query; "lakehouse" products such as Databricks blur the line.

Keep analytics out of the transactional database. Say that events and nightly extracts flow into a warehouse or lake, where analysts and batch jobs run, so heavy queries never slow the user-facing system. See also "OLTP vs. OLAP" and "Batch processing".

Dead letter queue

Category: messaging and streaming.

A queue where messages are moved after they have failed processing a set number of times, so they stop blocking the main queue and can be inspected, fixed and replayed.

Mention it whenever you draw a queue with workers: "retry three times with backoff, then move to a dead letter queue with alerting". It shows you have thought about poison messages and about operations, not only the happy path. See also "Retries" and "Message queue".

Delivery semantics (at-most-once, at-least-once, exactly-once)

Category: messaging and streaming.

What a messaging system promises about each message. At-most-once: fire and forget, messages can be lost but never duplicated. At-least-once: the producer retries and the consumer acknowledges after processing, so nothing is lost but duplicates happen. Exactly-once: each message takes effect once; in practice achieved by at-least-once delivery plus idempotent or transactional processing (Kafka offers it within its own ecosystem).

Default to at-least-once plus idempotent consumers, and say so. When an interviewer asks "what if the message is delivered twice?", the answer is an idempotency key or a deduplication table, not "the queue guarantees exactly-once". See also "Idempotency".

Denormalization (and normalization)

Category: databases and storage.

Normalization organises relational data so that each fact is stored once (separate tables for users, orders, products, joined by keys), which keeps writes simple and consistent. Denormalization deliberately copies data (storing the author's name on each post, pre-joined documents, counters) so reads need fewer joins and are faster.

Start normalised for the write model, then denormalise where read volume demands it, and say how the copies are kept up to date (events, background jobs, or accepting staleness). NoSQL data modelling is largely denormalisation driven by the queries you need. See also "Materialized view" and "Wide-column store".

Deployment strategies (blue-green, canary, rolling)

Category: operations.

Ways to release a new version without downtime. Rolling: replace instances a few at a time. Blue-green: run the new version next to the old one and switch traffic at once, keeping the old one for instant rollback. Canary: send a small share of traffic (1%, then 10%) to the new version and watch error rates before rolling out further.

Rarely the main topic, but a sentence about canary releases and automatic rollback on error-rate increase rounds off the reliability discussion. Note that database schema changes must be backward compatible for any of these to work.

Disaster recovery (RPO, RTO)

Category: availability and reliability.

Planning for the loss of a whole data centre or region, or for data corruption. RPO (recovery point objective) is how much data you may lose, measured in time since the last usable backup or replica. RTO (recovery time objective) is how long the system may be down while you recover. Backups, cross-region replicas and tested restore procedures are the tools.

Ask for RPO and RTO when the question is about availability, because they decide between nightly backups (RPO of hours), asynchronous cross-region replication (RPO of seconds) and synchronous replication (RPO of zero, at a latency cost). An untested backup is not a backup. See also "Multi-region architecture" and "Failover".

Distributed lock

Category: distributed systems.

A lock that processes on different machines can take to make sure only one of them does something at a time: running a scheduled job, processing a particular account, resizing one image. Implemented with a coordination service (ZooKeeper ephemeral nodes, etcd leases) or with Redis (SET with NX and an expiry, and the contested Redlock algorithm). Locks must expire so a crashed holder does not block everyone, and a fencing token (an increasing number handed out with the lock) lets the protected resource reject a stale holder whose lock expired while it paused.

Say first whether you can avoid the lock (idempotent operations, partitioning the work by key, or a database transaction). If you still need one, name the expiry, what happens if the holder dies, and the fencing token. See also "Coordination service" and "Leader election".

Distributed transactions (two-phase commit, 2PC)

Category: distributed systems.

A transaction that must commit atomically across several databases or services. Two-phase commit uses a coordinator: it asks every participant to prepare (write everything and promise to commit), and only when all say yes does it tell them to commit. It is correct but slow, and if the coordinator crashes after the prepare phase, participants are stuck holding locks until it returns.

The usual advice is to avoid it: keep data that must change together in one database, or use the saga pattern with compensating actions. Mention 2PC as the strict option and explain why you are not using it. Spanner, CockroachDB and some message brokers use it internally. See also "Saga pattern" and "Outbox pattern".

DNS

Category: networking and communication.

The system that turns a name such as api.example.com into IP addresses. Answers carry a TTL and are cached by resolvers, so changes propagate slowly. DNS can also route: GeoDNS returns a nearby region's address, weighted records split traffic, and health-checked records drop a failed region. Anycast announces the same IP from many places and lets the network route to the nearest one (used by CDNs and public DNS).

DNS is the first hop of every request and the usual way to send users to the right region. Note its weakness for failover: cached answers mean some clients keep hitting a dead address until the TTL expires, so keep TTLs short for records you may need to change. See also "Multi-region architecture" and "Load balancer".

Document store

Category: databases and storage.

A NoSQL database that stores self-contained JSON-like documents with flexible schemas: MongoDB, Couchbase, Amazon DocumentDB, Firestore. A document usually holds everything one screen needs (an order with its lines), which avoids joins but duplicates data.

Good for data that is naturally hierarchical and read as a whole, and for fast-changing schemas. Weak for many-to-many relationships and cross-document transactions (MongoDB supports multi-document transactions, but they are not its strength). See also "NoSQL" and "Relational database".

Durability

Category: availability and reliability.

The guarantee that once the system has acknowledged a write, the data will not be lost, even if a machine crashes or a disk dies. Achieved by writing to a write-ahead log before acknowledging, replicating to other machines (ideally in another zone) and taking backups. Object storage services advertise "eleven nines" (99.999999999%) of durability per year.

Different from availability: a system can be down yet lose nothing, or up and losing data. For anything users would be upset to lose, say when you acknowledge the write (after the leader's log, or after one replica confirms) and name the trade-off with latency. See also "Write-ahead log" and "Replication".

E

Encryption in transit and at rest (TLS)

Category: security.

In transit: TLS (HTTPS) between clients and servers and, increasingly, between internal services (mTLS). TLS is usually terminated at the load balancer or API gateway. At rest: disk and database encryption, with keys in a key-management service (KMS), plus field-level encryption for the most sensitive values.

One or two sentences unless the question is security-focused: "TLS everywhere, terminated at the gateway; data encrypted at rest with KMS-managed keys; secrets in a vault, never in code". Add hashing for passwords and tokenisation for card numbers if payments are involved.

Event-driven architecture

Category: architecture patterns.

Services communicate by publishing events ("order placed") to a broker, and any service that cares subscribes, rather than calling each other directly. Producers do not know who consumes, which decouples teams and lets new consumers be added without changing the producer.

Use it when one action triggers several independent reactions (an order updates inventory, sends an e-mail, starts shipping, feeds analytics). Say what happens to events when a consumer is down (the broker keeps them) and how you handle ordering and duplicates. It is not the same as event sourcing. See also "Pub/sub", "Event streaming" and "Event sourcing".

Event sourcing

Category: architecture patterns.

Storing the full sequence of events that happened to an entity (account opened, 100 deposited, 30 withdrawn) as the source of truth, and deriving the current state by replaying them. Snapshots speed up replay; projections build read models.

Fits domains that need a complete audit trail or time travel: ledgers, order histories, version control. The costs are real: queries need projections, schema changes to old events are painful, and the volume grows forever. Propose it only when the audit trail is a requirement, and usually together with CQRS. See also "CQRS".

Event streaming (Kafka)

Category: messaging and streaming.

A durable, ordered, append-only log of events, split into partitions, that many consumers can read at their own pace and re-read from any offset. Apache Kafka is the standard; Amazon Kinesis, Apache Pulsar and Redpanda are alternatives. Unlike a traditional queue, messages are not deleted when consumed; they are kept for a retention period (days or longer).

Choose it over a plain queue when several consumers need the same events, when you need replay (rebuilding a cache or a new read model from history), or at very high throughput. Explain partitioning by key (ordering is guaranteed only within a partition) and consumer groups (each partition is read by one consumer in the group, which is how you scale). See also "Message queue" and "Pub/sub".

Eventual consistency

Category: distributed systems.

The promise that if no new writes are made, all replicas will eventually hold the same value. Until then a read may return stale data. It is what asynchronous replication, caches with a TTL and most NoSQL stores give you.

Say where it is acceptable (feeds, counters, search results, recommendations) and where it is not (balances, inventory at checkout, access control). Then make it concrete: how stale, and what the user experiences. Offer read-your-writes for the user's own data when it matters. See also "Consistency models".

F

Failover

Category: availability and reliability.

Switching from a failed component to a standby: promoting a replica to primary when the database leader dies, moving a virtual IP to the standby load balancer, or sending traffic to another region. It can be manual or automatic; automatic failover needs reliable failure detection to avoid promoting a replica while the old leader is still alive (split brain).

For every stateful component, say what fails over to what, how failure is detected (heartbeats, health checks), how long it takes, and what data can be lost (asynchronous replicas may be behind). See also "Split brain", "Replication" and "Heartbeat and health checks".

Fan-out (on write vs. on read)

Category: architecture patterns.

How a social feed is built. Fan-out on write (push): when a user posts, the system writes the post into the pre-computed feed of every follower, so reading a feed is one lookup. Fan-out on read (pull): a feed is assembled at read time by fetching the latest posts of everyone the user follows. Push makes reads cheap and writes expensive; pull is the opposite.

The classic Twitter or Instagram deep dive. The expected answer is a hybrid: push for ordinary users, pull for accounts with millions of followers (the "celebrity problem"), merged at read time. Mention the cost of pushing to inactive users and the storage for precomputed feeds. See also "Hot spot".

Fault tolerance

Category: availability and reliability.

The ability of a system to keep working, possibly in a reduced way, when some of its parts fail. It comes from redundancy (no single point of failure), failure detection, failover, and isolation so that one failure does not cascade.

Walk through the design and ask of each box "what if this dies?" Stateless servers: the load balancer routes around them. Database: replicas and failover. Cache: fall back to the database, with care about the thundering herd. Queue: replicated broker. Whole zone: multi-zone deployment. See also "Single point of failure" and "Graceful degradation".

Functional and non-functional requirements

Category: interview method.

Functional requirements are what the system does (post a message, search by name, upload a file). Non-functional requirements are the qualities it must have: scale (users, requests, data), latency targets, availability, consistency, durability, security, cost. The non-functional ones drive most of the architecture.

Spend the first few minutes agreeing on three to five functional requirements and the key non-functional numbers, and write them down. Interviewers want to see you narrow the scope and ask about read/write ratio, latency and consistency before drawing anything. See also "Back-of-the-envelope estimation".

G

Geospatial indexing (geohash, quadtree, S2, H3)

Category: data and algorithms.

Ways to index locations so that "everything within 2 km of here" is a cheap query. A geohash encodes latitude and longitude into a string whose prefixes describe ever larger cells, so nearby points share prefixes and the query becomes a prefix search. A quadtree splits the map into four recursively until each cell holds few points. Google's S2 and Uber's H3 are hierarchical cell systems with better behaviour at cell edges. PostGIS and Redis GEO offer such queries out of the box.

Needed for Uber, Yelp and "find nearby" questions. Explain that a naive query on raw coordinates scans everything, pick one indexing scheme, and mention searching the neighbouring cells too so points just across a boundary are not missed. Separate the slowly changing data (restaurants) from the fast-moving one (drivers, updated every few seconds, often kept in memory).

Gossip protocol

Category: distributed systems.

Nodes periodically exchange what they know with a few random peers, so information (membership, health, metadata) spreads through the cluster in a logarithmic number of rounds without a central coordinator. Cassandra, Consul and Dynamo-style systems use it.

A one-line mention when explaining how a leaderless cluster knows which nodes are alive. It is eventually consistent and robust, not fast or precise, so it is not a replacement for consensus where agreement is required.

Graceful degradation

Category: availability and reliability.

Designing so that when a part fails the system loses a feature rather than the whole experience: show the product page without recommendations, serve a slightly stale feed from cache, accept orders and queue them when the payment provider is slow.

After the normal flow, say what each failure costs the user and which features you would switch off first. Combined with circuit breakers and feature flags it turns "the system is down" into "a feature is degraded". See also "Fault tolerance" and "Load shedding".

Graph database

Category: databases and storage.

A database that stores nodes and edges directly and is optimised for traversals: "friends of friends", shortest path, fraud rings. Neo4j, Amazon Neptune and JanusGraph are examples. The same data can be held in a relational table of edges, but multi-hop queries become expensive joins.

Propose it only when traversal depth is the core of the problem (social graph queries, recommendations, knowledge graphs). For "who follows whom" served one hop at a time, a relational or key-value store with a well-chosen key is usually simpler and scales more predictably.

GraphQL

Category: networking and communication.

An API style where the client sends a query describing exactly the fields it wants and the server returns that shape, from a single endpoint. It replaces many REST endpoints and avoids over-fetching, at the cost of a more complex server (resolvers, the N+1 query problem, caching that is harder than for REST URLs).

Reasonable for a public API serving many different clients with varied needs, or for a mobile app that wants to minimise round trips. For service-to-service traffic prefer gRPC; for a simple API prefer REST. Mention rate limiting by query cost, not by request count. See also "REST" and "gRPC".

gRPC

Category: networking and communication.

A remote procedure call framework from Google that uses HTTP/2 and Protocol Buffers: a strongly typed contract, compact binary messages, generated client code, and support for streaming in both directions. It is the common choice for communication between internal services; browsers need a proxy layer (gRPC-Web).

Use it for internal, latency-sensitive calls between services, and REST or GraphQL for public APIs. The trade-off is binary payloads that are not human-readable and a schema that must be managed. See also "Serialization formats" and "REST".

H

Heartbeat and health checks

Category: availability and reliability.

Periodic signals used to detect failure. A health check is a request the load balancer or orchestrator makes to each instance ("are you alive and able to serve?"); instances that fail several checks in a row are removed from rotation. A heartbeat is the reverse: a node reports regularly to a coordinator, and silence for a few intervals means it is presumed dead.

Say how each failure is detected before saying how it is handled. Mention the trade-off in the timeout: too short produces false alarms during garbage-collection pauses or network hiccups, too long delays failover. Distinguish a shallow check (process responds) from a deep one (can reach the database). See also "Failover".

Hot spot (hot key, hot partition)

Category: scalability.

A single key, user, partition or shard that receives far more traffic than the others, so that the system is bottlenecked on one node while the rest sit idle: a celebrity's profile, a viral post, a flash-sale product, or a shard key that puts today's data on one shard.

Any time you shard or cache by key, say how you would spot and handle hot keys: choose a shard key that spreads load (hash of user ID rather than timestamp), add a local in-process cache in front of the distributed cache for the hottest keys, replicate hot partitions to more nodes, split a hot key into several sub-keys with a random suffix, and protect it with rate limiting. See also "Sharding" and "Fan-out".

HTTP caching (Cache-Control, ETag)

Category: caching.

The caching rules built into HTTP. Cache-Control headers tell browsers, CDNs and proxies how long a response may be reused (max-age) and whether shared caches may store it. An ETag is a version identifier; the client sends it back and the server answers "304 Not Modified" if nothing changed, saving the body transfer.

The cheapest cache you can add, since it needs no infrastructure. Use long max-age with versioned file names for static assets and short max-age or ETags for API responses that change. See also "CDN".

HyperLogLog

Category: data and algorithms.

A probabilistic structure that estimates the number of distinct items in a stream (unique visitors, unique search terms) with about 1-2% error using only a few kilobytes, regardless of how many items there are. Redis implements it (PFADD, PFCOUNT).

The answer for "count unique users per day per page across billions of events" when storing every user ID per page would be too big. Make clear it is approximate and cannot list the members. See also "Bloom filter" and "Count-min sketch".

I

Idempotency

Category: distributed systems.

An operation is idempotent if doing it twice has the same effect as doing it once. "Set balance to 100" is idempotent; "add 10 to balance" is not. Since networks and queues deliver duplicates and clients retry after timeouts, non-idempotent operations need an idempotency key: the client sends a unique ID with the request, and the server stores the result under that key and returns the same result on a repeat.

Essential for payments, order creation and any at-least-once consumer. When an interviewer asks "what if the client retries?" or "what if the message is delivered twice?", answer with an idempotency key stored with the result and a TTL. Stripe's Idempotency-Key header is the well-known example. See also "Delivery semantics" and "Retries".

Inverted index (full-text search)

Category: databases and storage.

The structure behind search engines: a mapping from each term to the list of documents containing it (and positions), the reverse of a document-to-words layout. Lucene, and the systems built on it (Elasticsearch, OpenSearch, Solr), add tokenisation, stemming, ranking (such as BM25) and sharding of the index.

When a question has "search" in it, do not propose SQL LIKE queries. Put a search service with an inverted index next to the primary database, keep it updated through events or CDC, and accept that it is eventually consistent with the source of truth. See also "Trie" for prefix autocomplete and "Change data capture".

Isolation levels (and serializability)

Category: databases and storage.

How much concurrent transactions may see of each other. From weakest to strongest: read uncommitted, read committed (the default in PostgreSQL and Oracle), repeatable read or snapshot isolation (the default in MySQL InnoDB; each transaction sees a consistent snapshot), and serializable (the result is as if transactions ran one after another). Weaker levels allow anomalies such as non-repeatable reads, phantom reads and write skew; stronger levels cost throughput or cause more aborts.

Relevant for bookings, inventory and transfers: "two users book the last seat at the same time". Either use serializable isolation, or stay at a weaker level and add explicit locking or a version check. Knowing that the default is usually not serializable is the point. See also "Optimistic vs. pessimistic locking" and "Linearizability".

K

Key-value store

Category: databases and storage.

The simplest database model: get, put and delete by key, with no joins or secondary queries. In-memory stores such as Redis and Memcached are used as caches and for fast data structures (Redis also offers lists, sorted sets, streams and pub/sub); persistent ones such as DynamoDB, Riak and RocksDB scale horizontally by partitioning on the key.

The default for sessions, caches, counters, rate-limit buckets, feature flags, user-to-shard lookups and anything accessed only by a known key. Mention the limitation: if you need to query by anything other than the key, you must maintain a second index yourself. See also "Cache", "NoSQL" and "Consistent hashing".

L

Latency

Category: fundamentals.

The time a single request takes from send to response, usually measured at percentiles (p50, p95, p99) rather than as an average, because averages hide the slow tail. Network round trips, disk access, queueing and downstream calls add up along the critical path.

State a target ("p99 under 200 ms for the feed") and then design to it: fewer sequential network hops, caching, data close to users (CDN, regions), asynchronous work off the critical path. Latency and throughput are different things; a system can be fast per request and still unable to handle the load. See also "Tail latency" and "Throughput".

Leader election

Category: distributed systems.

Choosing one node among several to be the one that accepts writes, runs a scheduled job or coordinates the others, and choosing a new one when it fails. Done safely through a consensus-based coordination service (a lease or ephemeral node that only one holder can own), or in simple setups by a fixed priority with a monitor (the bully algorithm). The danger is two nodes both believing they are the leader.

Mention it when you have a single-leader database, a singleton scheduler, or a partition assigner. Say what the lease timeout is and how the old leader is stopped from acting when its lease expired (fencing). See also "Split brain", "Coordination service" and "Consensus".

Leaderless replication (Dynamo-style)

Category: distributed systems.

Replication where any replica accepts writes and reads, and clients (or a coordinator) send each request to several replicas in parallel, waiting for a quorum of acknowledgements. Stale replicas are fixed by read repair (the client writes back the newest version to lagging replicas) and anti-entropy (background comparison of replicas, often with Merkle trees); hinted handoff stores writes meant for a down node temporarily on a neighbour. Amazon's Dynamo paper (2007) defined the pattern; Cassandra, Riak and ScyllaDB follow it.

The model behind "always writable" stores. Explain quorum reads and writes (W + R > N) and tunable consistency per request, and admit the costs: conflicts to resolve and no transactions. See also "Quorum" and "Conflict resolution".

Linearizability

Category: distributed systems.

The strongest practical consistency guarantee for a single object: every operation appears to take effect instantly at some point between its start and its end, so once a write is acknowledged every later read, from any client, sees it. It is what people usually mean by "strong consistency" and what CAP's "C" means. It is not the same as serializability, which is about transactions over many objects; databases that offer both are called strictly serializable.

Say you need it for things such as uniqueness checks (one username, one seat), leader election and locks, and that it requires either a single leader or consensus, which limits availability during partitions and adds latency across regions. See also "Consistency models" and "Isolation levels".

Load balancer

Category: networking and communication.

A component that spreads incoming requests across a pool of servers, removes unhealthy ones using health checks and makes the pool look like one address. Layer 4 balancers route by IP and port and are very fast; layer 7 balancers understand HTTP and can route by path, host or header, terminate TLS and do sticky sessions. Algorithms: round robin, weighted round robin, least connections, least response time, hashing on client IP or on a key. Examples: NGINX, HAProxy, Envoy, AWS ELB/ALB.

The first box after DNS in nearly every design. State the layer, the algorithm and the health check, and remember that the load balancer must not be a single point of failure (an active-passive pair with a floating IP, or the cloud provider's managed one). Load balancers can also sit between internal tiers. See also "API gateway" and "Reverse proxy".

Load shedding

Category: availability and reliability.

Deliberately dropping or rejecting some requests when the system is near its capacity, so that the remaining requests still succeed instead of everything slowing to a crawl and timing out. Usually done by priority: keep checkouts, drop analytics pings; keep logged-in users, reject anonymous crawlers; return 503 with a Retry-After header.

The honest answer to "what happens at ten times the expected load?" Autoscaling takes minutes; load shedding works in milliseconds. Pair it with rate limiting (per client) and backpressure (between components). See also "Rate limiting" and "Backpressure".

Long polling

Category: networking and communication.

A way to push updates to a client over plain HTTP: the client sends a request, the server holds it open until there is new data or a timeout passes, answers, and the client immediately sends the next request. It works through every proxy and firewall but costs a held connection per client and a request cycle per message.

Offer it as the simple option for notifications or chat when WebSockets are not available, and compare it with WebSockets (bidirectional, persistent) and server-sent events (one-way, persistent). See also "WebSocket" and "Server-sent events".

M

Materialized view

Category: databases and storage.

A query result stored as a table and refreshed periodically or incrementally, so that an expensive aggregation or join is computed once and read many times: daily sales per product, a user's follower count, a leaderboard.

Use it when the same heavy query backs a popular screen. Say how it is refreshed (on a schedule, by triggers, or from an event stream) and therefore how stale it may be. In a NoSQL design the same idea appears as a precomputed table built by a consumer. See also "CQRS" and "Denormalization".

Merkle tree

Category: data and algorithms.

A tree of hashes in which each leaf is the hash of a data block and each parent is the hash of its children, so the root summarises the whole data set. Two replicas can find which blocks differ by comparing hashes top-down, exchanging only a logarithmic number of hashes. Used for anti-entropy in Cassandra and Dynamo, in Git, in BitTorrent and in blockchains.

A one-sentence mention when explaining how replicas or file sync clients detect divergence efficiently without transferring all the data. See also "Leaderless replication" and "Chunking".

Message queue

Category: messaging and streaming.

A buffer between a producer and one or more consumers (workers). The producer puts a message in and moves on; a worker takes it, processes it and acknowledges it, after which it is removed; if the worker fails to acknowledge in time the message becomes visible again. RabbitMQ, Amazon SQS, ActiveMQ and Redis-based queues (Sidekiq, Celery) are typical. Each message is usually processed by one consumer.

The tool for asynchronous work, for smoothing out traffic spikes (the queue absorbs the burst and workers drain it) and for decoupling services so that a slow consumer does not slow the producer. Say what the visibility timeout is, that delivery is at-least-once, and that workers must be idempotent. See also "Event streaming", "Dead letter queue" and "Asynchronous processing".

Microservices vs. monolith

Category: architecture patterns.

A monolith is one deployable application with one codebase and usually one database. Microservices split the system into independently deployed services, each owning its data, communicating over the network. Microservices let teams scale and deploy independently and let each part use the right storage; they add network latency, partial failures, distributed data problems, and operational overhead. A "modular monolith" keeps clear internal boundaries without the network between them.

Do not default to microservices to look modern. Justify splits by scaling needs or team boundaries, and name the costs you take on (service discovery, observability, no cross-service transactions). For a system design interview, a handful of services around a clear domain is a good middle ground. See also "Service discovery" and "Saga pattern".

Multi-leader replication

Category: distributed systems.

Replication in which more than one node accepts writes (typically one leader per region or data centre) and leaders replicate to each other asynchronously. Writes are fast and local and the system survives a region outage, but concurrent writes to the same item in two regions conflict and must be resolved.

The usual choice for active-active multi-region designs and for offline-capable clients (each device is a "leader"). Follow it immediately with the conflict-resolution strategy, or avoid the problem by home-region routing: all writes for a given user go to that user's region. See also "Conflict resolution" and "Multi-region architecture".

Multi-region architecture

Category: availability and reliability.

Running the system in several geographic regions, either active-passive (one serves, the other is a warm standby with replicated data) or active-active (all serve, usually with users routed to the nearest region). It cuts latency for distant users, survives a whole-region outage and can satisfy data-residency laws, at the cost of cross-region replication lag, conflicts, and much more complexity.

Only go there when the requirements ask for global latency, very high availability or residency. Then be concrete: how users are routed (GeoDNS, anycast), how data is replicated (asynchronous, leader per region, or a globally consistent database such as Spanner or CockroachDB with its latency cost), and what happens during a failover (data loss window, DNS TTL). See also "Availability zones and regions" and "Disaster recovery".

Multi-tenancy

Category: architecture patterns.

Serving many customers (tenants) from one deployment while keeping their data and performance isolated. Options range from a tenant_id column in shared tables (cheapest, needs care in every query) through a schema or database per tenant to fully separate stacks for the largest customers.

Comes up in SaaS designs. Say how isolation is enforced (row-level security, tenant-scoped keys), how a noisy tenant is prevented from starving others (per-tenant rate limits and quotas), and how you would shard by tenant.

N

Network partition

Category: distributed systems.

A failure in which nodes are alive but cannot reach each other (a cut link, a misconfigured switch, a zone isolated), so each side may continue to operate on its own view of the data. It is the "P" in CAP and the situation that forces the choice between consistency and availability.

When you describe replication or clustering, say what each side does during a partition: the minority side refuses writes (consistency) or keeps accepting them and reconciles later (availability). Note that from inside a node a partition looks the same as a crashed peer. See also "CAP theorem" and "Split brain".

NoSQL

Category: databases and storage.

A family of databases that give up parts of the relational model (fixed schemas, joins, multi-row transactions) in exchange for horizontal scaling, flexible data and high write throughput. Four main types: key-value (Redis, DynamoDB), document (MongoDB), wide-column (Cassandra, HBase, Bigtable) and graph (Neo4j).

"NoSQL" is not a choice; a specific store and a reason is. Reach for one when the data volume or write rate exceeds what a single relational node and read replicas handle, when the access pattern is simple key lookups, or when the schema varies widely. Otherwise start with a relational database. Be ready to explain how you model the data around the queries, because you cannot add arbitrary joins later. See also "Relational database", "Key-value store", "Document store" and "Wide-column store".

O

Object storage (S3, blob storage)

Category: databases and storage.

A service that stores files of any size as objects under a key, with HTTP access, very high durability, practically unlimited capacity and low cost per gigabyte: Amazon S3, Google Cloud Storage, Azure Blob Storage, MinIO. Objects are written whole and read whole or by byte range; there is no file system or in-place editing. Pre-signed URLs let a client upload or download directly, bypassing your servers.

The home for every large binary: photos, videos, backups, exports, data-lake files. Keep only metadata (owner, key, size, status) in the database, upload directly from the client with a pre-signed URL, and serve through a CDN. Do not put files in the database. See also "CDN" and "Chunking".

Observability (logs, metrics, traces)

Category: operations.

Being able to tell what a system is doing from the outside. Logs are per-event records; metrics are numbers over time (request rate, error rate, latency percentiles, queue depth, saturation); traces follow one request across services with a shared trace ID. OpenTelemetry is the common standard; Prometheus and Grafana, the ELK stack, Jaeger and Datadog are typical tools.

Close the design with how you would know it works: dashboards on the key metrics, alerts on SLO violations, and distributed tracing since a request crosses several services. Name the four golden signals: latency, traffic, errors, saturation. See also "SLA, SLO and SLI".

OLTP vs. OLAP

Category: databases and storage.

OLTP (online transaction processing) workloads are many small reads and writes touching a few rows each, with low latency and strong consistency: the user-facing database. OLAP (online analytical processing) workloads scan millions of rows to aggregate: reports, dashboards, data science. They need different storage (row-oriented vs. column-oriented) and should run on different systems.

Never run analytics on the production OLTP database. Copy data out (CDC, nightly export, event stream) into a warehouse built for OLAP. See also "Data warehouse and data lake".

Optimistic vs. pessimistic locking

Category: databases and storage.

Two ways to handle concurrent updates to the same row. Pessimistic: lock the row when reading it (SELECT ... FOR UPDATE) so others wait; safe, but locks held across user think-time or slow calls hurt throughput. Optimistic: read a version number along with the row, do the work, and write with "WHERE version = the one I read"; if zero rows update, someone else got there first and you retry. Compare-and-set operations in key-value stores are the same idea.

The answer to double-booking, inventory oversell and lost-update questions. Optimistic locking suits low-contention cases (most edits do not collide); pessimistic suits high-contention, short transactions. For a flash sale with one hot item, neither scales and you move to a queue or a pre-allocated counter. See also "Isolation levels".

Outbox pattern

Category: architecture patterns.

A way to update a database and publish an event atomically without distributed transactions: the service writes the business row and an "outbox" row describing the event in the same local transaction; a separate relay process (or CDC) reads the outbox and publishes to the broker, marking rows as sent. Consumers may see duplicates, so they are idempotent.

The fix for "what if the database commit succeeds but publishing the event fails?" (or the reverse). It is the standard way to make event-driven and saga-based designs reliable. See also "Change data capture", "Saga pattern" and "Idempotency".

P

Pagination (offset vs. cursor)

Category: networking and communication.

Returning a long list in pages. Offset pagination ("page 50, 20 per page") is simple but gets slower the deeper you go (the database still walks past the skipped rows) and shifts items when the list changes between requests. Cursor (keyset) pagination returns an opaque token pointing at the last item seen (usually its sort key) and the next request continues from there; it is fast at any depth and stable under inserts.

Use cursors for feeds, timelines and infinite scroll, and say the cursor is based on an indexed sort key such as (created_at, id). Offsets are fine for small admin tables.

Peer-to-peer (P2P)

Category: architecture patterns.

An architecture without central servers where each participant both consumes and provides the service: BitTorrent for file distribution, some video-call media paths, blockchain networks. Discovery, trust and NAT traversal are the hard parts.

Rare as a main topic; it appears in questions about distributing very large files to many clients (software updates, game patches), where a tracker plus peers reduces the origin's bandwidth. For most products a CDN is the practical answer.

Push vs. pull

Category: architecture patterns.

Whether the producer sends data to consumers as it happens (push: WebSockets, webhooks, notifications, fan-out on write) or consumers ask for it when they need it (pull: polling, fan-out on read, consumers fetching from Kafka). Push gives low latency and can overwhelm slow consumers; pull lets consumers control their pace at the cost of delay and wasted empty requests.

Many deep dives reduce to this choice: feed building, notification delivery, metrics collection (Prometheus pulls), cache refreshing. Name both options, pick one per use case and give the reason. See also "Fan-out" and "Backpressure".

Q

Quorum

Category: distributed systems.

The minimum number of replicas that must take part in an operation for it to count. With N replicas, if a write waits for W acknowledgements and a read queries R replicas, then W + R > N guarantees that every read overlaps at least one replica holding the latest write. Typical: N = 3, W = 2, R = 2. Consensus protocols need a majority quorum, which is why clusters have 3 or 5 nodes.

Use it to explain tunable consistency in Cassandra or DynamoDB ("quorum reads and writes for the balance, one replica for the activity log") and why a 5-node cluster survives two failures. Quorums give overlap, not full linearizability, once writes conflict or fail half-way. See also "Leaderless replication" and "Consensus".

R

Rate limiting (token bucket, leaky bucket, sliding window)

Category: availability and reliability.

Capping how many requests a client, user, API key or IP may make per period, returning 429 when exceeded. Token bucket: tokens drip into a bucket at a fixed rate, each request takes one, bursts are allowed up to the bucket size (the most common choice). Leaky bucket: requests drain at a fixed rate, smoothing bursts. Fixed window counters are simple but allow double bursts at the boundary; a sliding window log or sliding window counter fixes that. Distributed implementations keep counters in Redis.

A full question in its own right and a line in most others. Say where it runs (API gateway), what the key is, which algorithm, how counters are shared across gateway instances (Redis with atomic operations, or local counters with eventual sync), and what the client is told (429 plus Retry-After and rate-limit headers). See also "Load shedding".

Read replicas (and replication lag)

Category: scalability.

Copies of the database that receive changes from the primary (usually asynchronously) and serve read queries, multiplying read capacity and providing failover candidates. Because replication is asynchronous, a replica may be behind by milliseconds or, under load, seconds: replication lag. A user who writes and then reads from a lagging replica may not see their own change.

The first step in scaling a read-heavy relational database, after caching. Then handle lag: read the user's own writes from the primary (or pin the user to the primary for a few seconds after a write), and route only latency-tolerant reads to replicas. Replicas do not add write capacity; that needs sharding. See also "Replication", "Sharding" and "Consistency models".

Relational database (SQL)

Category: databases and storage.

A database of tables with fixed schemas, joined by keys and queried with SQL, offering ACID transactions and secondary indexes on any column: PostgreSQL, MySQL, SQL Server, Oracle. One well-tuned node handles thousands to tens of thousands of simple queries per second and terabytes of data; beyond that you add replicas, caches and eventually sharding (manually, or with tools such as Vitess and Citus, or with distributed SQL databases such as CockroachDB and Spanner).

The right default for structured data with relationships and for anything needing transactions. Show the schema, the indexes and the growth plan, and switch to NoSQL only with a stated reason. See also "NoSQL", "ACID" and "Database index".

Replication (single-leader)

Category: distributed systems.

Keeping copies of the same data on several nodes. In single-leader (primary-replica) replication, one node accepts all writes and streams them to followers, which serve reads and can be promoted on failure. Synchronous replication waits for a follower to confirm before acknowledging (no data loss on failover, higher latency); asynchronous does not (fast, but a failover may lose the last writes); semi-synchronous waits for one follower. Multi-leader and leaderless replication relax the single-writer rule at the price of conflicts.

Replication is for availability and read scaling, not for write scaling. State the mode (synchronous or asynchronous), the number of replicas and their placement across zones, and what a failover costs in time and possibly lost data. See also "Read replicas", "Multi-leader replication", "Leaderless replication" and "Failover".

REST

Category: networking and communication.

The dominant style for HTTP APIs: resources identified by URLs (/users/42/orders), standard methods (GET to read, POST to create, PUT or PATCH to update, DELETE), status codes for outcomes, JSON bodies, and stateless requests that carry everything the server needs. Caching and load balancing work naturally because requests are self-contained.

Sketch the main endpoints early (three to six, with the key fields) and mention versioning, pagination, idempotent PUTs and rate limits. Choose REST for public and simple APIs, gRPC for internal calls, GraphQL when clients need flexible queries. See also "gRPC" and "GraphQL".

Retries (exponential backoff and jitter)

Category: availability and reliability.

Repeating a failed call, waiting longer each time (exponential backoff: 100 ms, 200 ms, 400 ms...) with a random element (jitter) so that thousands of clients do not retry in lock-step, up to a limit. Retries are only safe for idempotent operations and for failures that may be transient (timeouts, 503s, connection resets), not for 400s or business errors.

Say "retry with exponential backoff and jitter, capped, only for idempotent requests, with a circuit breaker so retries do not amplify an outage". Retry storms, where every layer retries and the load multiplies, are a classic way to turn a small failure into a big one. See also "Idempotency", "Circuit breaker" and "Timeouts".

Reverse proxy

Category: networking and communication.

A server that sits in front of backend servers and forwards client requests to them, hiding the backends and handling TLS termination, compression, caching, static files and basic routing. NGINX, HAProxy, Envoy and Caddy are common. A load balancer is a reverse proxy that focuses on distributing load; an API gateway is a reverse proxy that understands the API.

Usually appears as part of the load balancer or gateway box. Mention it when you need TLS termination, response caching or static file serving in front of application servers. See also "Load balancer" and "API gateway".

S

Saga pattern

Category: architecture patterns.

A way to run a business transaction across several services without a distributed transaction: a sequence of local transactions, each publishing an event or calling the next step, with a compensating action for each step to undo it if a later step fails (cancel the reservation, refund the payment). Choreography: services react to each other's events. Orchestration: a central coordinator tells each service what to do and tracks state.

The answer to "how do you place an order that touches inventory, payment and shipping, each in its own service?" Name the steps and their compensations, choose orchestration for anything beyond three steps (easier to see state and to debug), and make each step idempotent. Accept that the system is briefly inconsistent in the middle. See also "Distributed transactions" and "Outbox pattern".

Scalability (horizontal vs. vertical)

Category: scalability.

The ability to handle more load by adding resources. Vertical scaling (scaling up) means a bigger machine: simple, no code changes, but has a ceiling and a single point of failure. Horizontal scaling (scaling out) means more machines: practically unlimited for stateless services, but state (databases, sessions, caches) must be partitioned or replicated, and the system becomes distributed.

Make the stateless tier horizontally scalable behind a load balancer, keep state in dedicated stores, and scale those with caching, replicas and sharding. Vertical scaling of the database is a legitimate first step, and saying so shows judgement. See also "Stateless vs. stateful services" and "Sharding".

Scatter-gather

Category: architecture patterns.

Sending one query to many partitions or services in parallel and merging the answers: a search over a sharded index, a price comparison across providers, a count across shards. The latency is that of the slowest participant, so tail latency matters, and the merge step needs the partial results to be combinable (top-K from each shard, then top-K overall).

Appears whenever your shard key does not match the query ("find all orders over 100 PLN" across shards keyed by user). Mention hedged requests or timeouts for slow shards and returning partial results when a shard is down. See also "Sharding" and "Tail latency".

Serialization formats (JSON, Protocol Buffers, Avro)

Category: networking and communication.

How data is encoded for the wire or for storage. JSON is human-readable, schemaless and verbose. Protocol Buffers (Protobuf), Thrift and Avro are binary, schema-based, several times smaller and faster to parse, and support schema evolution (adding fields without breaking old readers) when the rules are followed. Avro is common in Kafka with a schema registry; Protobuf is used by gRPC.

JSON for public APIs, a binary format for internal services and high-volume events. Mention backward and forward compatibility: consumers and producers are deployed at different times, so a schema change must be readable by both old and new versions. See also "gRPC" and "Event streaming".

Serverless (FaaS)

Category: architecture patterns.

Running code as functions that the cloud provider starts on demand, scales automatically and bills per invocation: AWS Lambda, Google Cloud Functions, Azure Functions. No servers to manage, scales to zero, but functions have cold-start latency, execution time limits, no local state and limited control over connection pooling to databases.

Good for spiky, event-triggered work (image processing after an upload, webhooks, scheduled jobs) and for low-traffic APIs. Less good for latency-sensitive, high-throughput services, where always-on containers are cheaper and more predictable. See also "Asynchronous processing" and "Connection pooling".

Server-sent events (SSE)

Category: networking and communication.

A standard way for a server to push a stream of text events to a browser over one long-lived HTTP response. One direction only (server to client), automatic reconnection built into browsers, simple to run through proxies and load balancers.

The lightweight answer for live updates that only flow one way: notifications, dashboards, progress of a long job, streamed AI responses. For chat or anything where the client also sends frequent messages, use WebSockets. See also "WebSocket" and "Long polling".

Service discovery

Category: networking and communication.

How services find the current addresses of other services when instances come and go. A registry (Consul, etcd, Eureka, or the DNS built into Kubernetes) holds healthy instances; clients either query it directly and balance themselves (client-side discovery) or call a stable address behind a load balancer or service mesh that does the lookup (server-side discovery).

One or two sentences when you introduce several services: "instances register with the service registry on start-up with health checks; calls go through the mesh or an internal load balancer". See also "Service mesh" and "Heartbeat and health checks".

Service mesh

Category: networking and communication.

An infrastructure layer (Istio, Linkerd, Consul Connect) that puts a small proxy (a sidecar, typically Envoy) next to each service instance and handles service-to-service concerns uniformly: mutual TLS, retries, timeouts, circuit breaking, traffic splitting and tracing, without changing application code.

Mention it as the place where cross-cutting resilience and security policies live in a large microservice deployment. Not needed for a few services; it adds latency and operational complexity.

Session management (sticky sessions)

Category: scalability.

Where a logged-in user's session state lives. Sticky sessions make the load balancer send a user to the same server every time, so state can stay in that server's memory; simple, but a server failure logs users out and load spreads unevenly. The scalable choice is stateless servers with the session in a shared store (Redis) or in a signed token (JWT).

Say "stateless servers, sessions in Redis with a TTL" and move on, unless the question is about WebSocket connections, where some stickiness is inherent and you need a way to find which server holds a user's connection. See also "Stateless vs. stateful services" and "Authentication and authorization".

Sharding (partitioning)

Category: scalability.

Splitting one large data set across several databases (shards), each holding a subset of the rows, so that writes and storage scale beyond one machine. The shard key decides where a row lives. Range sharding (by date or ID range) keeps related rows together but creates hot shards; hash sharding spreads load evenly but loses range queries; directory sharding keeps a lookup table and allows moving tenants. Costs: cross-shard queries and joins, transactions across shards, resharding when you grow, and hot spots.

The answer to "the writes exceed what one database handles" and "the data no longer fits". Choose the shard key from the most common query (user_id for a social app, so a user's data is on one shard), explain how you route a request to its shard, and how you would add shards later (consistent hashing or a directory, with a migration plan). Delay sharding as long as caching and replicas suffice; say so. See also "Consistent hashing", "Hot spot" and "Scatter-gather".

Single point of failure (SPOF)

Category: availability and reliability.

Any component whose failure takes down the whole system: one database, one load balancer, one message broker, one zone, one DNS provider, one person with the only credentials. Removing SPOFs means redundancy at every layer and tested failover.

After drawing the design, point at each box and say what happens if it dies. Interviewers often probe the load balancer, the primary database and the cache. The answer is always redundancy plus failure detection plus failover, with a note on what still degrades. See also "Fault tolerance" and "Failover".

SLA, SLO and SLI

Category: operations.

An SLI (service level indicator) is a measured quantity: the fraction of requests served under 300 ms, the fraction of successful responses. An SLO (objective) is the internal target for an SLI: 99.9% of requests succeed over 30 days. An SLA (agreement) is the external contract with customers, with penalties, and is usually looser than the SLO. The gap between 100% and the SLO is the error budget that can be spent on releases and risk.

Use the terms to turn "it should be fast and reliable" into numbers at the start, and to justify alerting and rollout policy at the end. See also "Availability" and "Observability".

Split brain

Category: distributed systems.

The situation in which a network partition leaves two nodes each believing they are the leader, both accepting writes, so the data diverges and cannot be cleanly merged. Prevented by requiring a majority quorum to be leader (so at most one side can have it), by leases that expire, and by fencing stale leaders from the shared resource.

Whenever you say "automatic failover", explain how you prevent split brain: the old primary is fenced off (STONITH in classic HA setups) or cannot get a quorum. Databases such as etcd and CockroachDB handle it; a home-made "promote the replica when the ping fails" script does not. See also "Leader election" and "Quorum".

Stateless vs. stateful services

Category: scalability.

A stateless service keeps nothing between requests that another instance would need: any instance can handle any request, so you can add, remove and replace instances freely. A stateful service holds data that matters (a database, a cache, a WebSocket connection, an in-progress upload) and must be replicated, partitioned or carefully handed over.

Push state out of the application tier into dedicated stores so the application tier scales trivially, and treat the stateful components as the real design problem. When you cannot avoid state in a service (long-lived connections), explain how clients find the right instance. See also "Scalability" and "Session management".

Stream processing (Flink, Kafka Streams, Spark Streaming)

Category: data processing.

Continuously processing events as they arrive, with results seconds or milliseconds old: real-time aggregations (views per minute), fraud detection, enrichment, alerting, maintaining materialized views. Engines keep state, group events into windows (tumbling, sliding, session), use watermarks to handle late events and checkpoint their state so they can recover without losing or duplicating results.

Choose it over batch when freshness matters (trending topics, live dashboards, monitoring). Say what the window is, where state lives, and how late or out-of-order events are handled. See also "Batch processing" and "Event streaming".

T

Tail latency (p99)

Category: fundamentals.

The latency experienced by the slowest requests, usually expressed as the 99th or 99.9th percentile. It matters more than the average because a page that makes 20 backend calls will hit the slow tail of at least one of them on most loads, and because the slowest requests are often the most valuable users with the most data. Causes: garbage-collection pauses, cache misses, hot keys, queueing, slow disks, retries.

Set targets at p99, not average. Techniques: hedged requests (send the same request to a second replica if the first is slow and take the first answer), timeouts with fallbacks, replicating hot data, and keeping fan-out small. See also "Latency" and "Scatter-gather".

TCP vs. UDP

Category: networking and communication.

TCP delivers bytes reliably and in order, with connection setup, acknowledgements, retransmission and congestion control; HTTP/1.1 and HTTP/2 run on it. UDP sends individual packets with no delivery or ordering guarantee and no connection, so it is faster and lighter; DNS, video calls, online games and HTTP/3 (through QUIC, which rebuilds reliability on top of UDP) use it.

Relevant for real-time media and gaming questions: a late video frame is useless, so UDP with application-level recovery beats TCP's retransmissions. For everything else, HTTP over TCP (or HTTP/3) is assumed. See also "WebSocket".

Throughput (QPS, bandwidth)

Category: fundamentals.

How much work a system completes per unit of time: requests or queries per second (QPS, RPS), messages per second, megabytes per second. Bandwidth is throughput of the network link. A system's throughput is limited by its narrowest component; raising it means parallelism (more instances, more partitions) or doing less work per request (caching, batching).

Estimate it in the first minutes (daily volume divided by about 100,000 gives per-second; multiply by two or three for peak) and compare it with what single components handle to decide where you need more than one node. See also "Back-of-the-envelope estimation" and "Latency".

Thundering herd (cache stampede)

Category: caching.

Many clients or requests hitting the same slow resource at the same moment: a popular cache entry expires and thousands of requests all miss and query the database together; a service restarts and every client reconnects at once; a cron job fires on every server at the same minute.

Say how you prevent it: only one request recomputes a missed key while the others wait or get the stale value (request coalescing, a lock on the key), refresh hot entries before they expire, add jitter to TTLs so entries do not expire together, and add jitter to retries and reconnects. Also plan a gradual warm-up when a cache is cold after a restart. See also "Cache" and "Retries".

Timeouts

Category: availability and reliability.

The maximum time a caller waits for a response before giving up. Without a timeout a hung dependency ties up a thread or connection forever and the failure spreads upward. Timeouts should be set per call, be shorter than the caller's own deadline, and be propagated so that a request that has already exceeded its budget is not still being processed downstream.

Every arrow between services carries a timeout, a retry policy and a fallback; say so once, explicitly. A typical pattern: connect timeout of tens of milliseconds, request timeout in the hundreds, and an overall request deadline passed along in a header. See also "Retries" and "Circuit breaker".

Time-series database

Category: databases and storage.

A database optimised for timestamped measurements that arrive in order and are queried by time range and aggregated: metrics, sensor data, prices. It compresses well, writes fast (append-only), downsamples old data (per second to per minute to per hour) and expires it by retention policy. InfluxDB, TimescaleDB (on PostgreSQL), Prometheus and ClickHouse are examples.

Use it for monitoring and IoT questions. Explain the write path (buffer, batch, append), the retention and downsampling policy, and that queries are mostly recent and aggregated. See also "Observability" and "B-tree and LSM tree".

Trie (prefix tree)

Category: data and algorithms.

A tree in which each node is one character and each path from the root spells a prefix, so all words starting with "sys" are found by walking three nodes and collecting the subtree. For autocomplete, each node can cache its most popular completions so a query returns the top suggestions in constant time.

The core of the typeahead or search-suggestions question. Cover building it offline from query logs, storing top-K at each node, updating it periodically rather than on every search, sharding by prefix, and serving it from memory behind a cache. See also "Inverted index".

TTL (time to live)

Category: caching.

An expiry attached to a piece of data: a cache entry, a DNS record, a session, a message in a queue, a short URL. When the TTL passes the item is removed or refreshed. It bounds staleness without explicit invalidation and keeps storage from growing forever.

Give every cache entry and every DNS record a TTL and say what it is, because it defines the staleness window the user can experience. Add jitter to TTLs of hot entries so they do not expire together. See also "Cache" and "Thundering herd".

U

Unique ID generation (UUID, Snowflake IDs)

Category: distributed systems.

Generating identifiers that are unique across many machines without a central counter. A UUID (128 bits; version 4 is random, version 7 is time-ordered) needs no coordination but is large and, for v4, random, which hurts B-tree index locality. Twitter's Snowflake scheme packs a 41-bit millisecond timestamp, a 10-bit machine ID and a 12-bit per-millisecond sequence into a 64-bit integer: compact, roughly time-sorted and generated locally. A database auto-increment is simplest but is a single point of failure and does not shard; a ticket server or key-generation service hands out ranges in advance.

A question on its own and a component in URL shorteners, messaging and feeds. State the requirements (uniqueness, size, sortability, no coordination) and pick accordingly; mention clock drift as the Snowflake weakness. See also "Base62 encoding" and "Clocks and ordering".

W

Webhook

Category: networking and communication.

An HTTP callback: a service calls a URL the customer registered when something happens (payment succeeded, repository pushed), instead of the customer polling. The sender must retry with backoff when the receiver is down, sign payloads so the receiver can verify them, and the receiver must handle duplicates.

The usual way to notify external systems. Describe the delivery service as a queue of events with retries, a dead letter queue, signing and an idempotency key in each delivery. See also "Retries" and "Idempotency".

WebSocket

Category: networking and communication.

A protocol that upgrades an HTTP connection into a persistent, bidirectional channel over which either side can send messages at any time with little overhead. The basis of chat, collaborative editing, live games, trading screens and presence indicators.

Use it when the client sends and receives frequent messages. Then handle the consequences: each server holds many open connections (and is therefore stateful), you need a way to find which server a user is connected to (a registry in Redis) and to route a message between servers (pub/sub), plus heartbeats to detect dead connections and reconnection logic on the client. Compare with SSE and long polling. See also "Server-sent events", "Long polling" and "Pub/sub".

Wide-column store (Cassandra, HBase, Bigtable)

Category: databases and storage.

A NoSQL model in which each row is identified by a partition key and holds many columns, often grouped and sorted by a clustering key, so that one partition holds, for example, all messages of a chat in time order. Data is distributed by partition key across many nodes (consistent hashing in Cassandra) and written with an LSM tree, giving very high write throughput and linear scaling. Queries must follow the key design; there are no joins and limited secondary indexes.

The go-to for write-heavy, time-ordered data at scale: chat messages, activity logs, sensor data, feeds. Design the table from the query ("get the last 50 messages of chat X") and say what the partition key and clustering key are. See also "NoSQL", "B-tree and LSM tree" and "Consistent hashing".

Write-ahead log (WAL)

Category: databases and storage.

An append-only file to which a database writes every change before applying it to its data structures. Because appends are sequential and fast, the database can acknowledge a write as soon as the log entry is on disk, replay the log after a crash to recover, and ship the log to replicas. PostgreSQL's WAL, MySQL's binlog and redo log, and the commit log in Cassandra are examples; Kafka is essentially a distributed WAL.

The mechanism behind durability, replication and change data capture. Mention it when explaining how a write is made safe before it is acknowledged, and why replicas and CDC tools read the log rather than the tables. See also "Durability" and "Change data capture".

How to Use This Glossary

Each entry names the area it belongs to, explains the term in plain language and then says, under "In interviews", when to bring it up, what to say and which trade-off to name. Search for a term with the field at the top of the glossary; many entries list alternative names in the title (e.g. "Sharding (partitioning)" or "Thundering herd (cache stampede)"), so searching for either one works.

Entries are grouped into areas so that you can study one area at a time: fundamentals, scalability, availability and reliability, caching, databases and storage, distributed systems, messaging and streaming, networking and communication, architecture patterns, data processing, media and content delivery, security, operations, data and algorithms, and interview method. Terms that appear as "See also" at the end of an entry are the ones interviewers tend to ask about next.

A Structure for the Interview

Most system design interviews last 45 to 60 minutes and reward a visible structure more than any particular technology. A sequence that works:

Requirements (about 5 minutes). Agree on three to five functional requirements and the non-functional ones that drive the design: number of users, read/write ratio, latency target, availability target, consistency needs, data retention. Write them down and narrow the scope out loud.
Estimation (about 5 minutes). Turn the requirements into requests per second, storage per year and bandwidth, at average and at peak. Use the numbers to decide where one machine is enough and where it is not.
High-level design (10 to 15 minutes). Draw clients, DNS, load balancer, the services, the database, the cache, the queue and the object storage, and show the main request flows. Sketch the data model and the key API endpoints.
Deep dive (15 to 20 minutes). Pick the two or three hardest parts, usually scaling the database (replication, sharding), the consistency model, a hot path (feed, search, matching) and failure handling. This is where most of the terms in this glossary belong.
Wrap-up (about 5 minutes). Walk through the design once more asking "what if this fails?", name the trade-offs you made, how you would monitor it, and what you would do next with more time.

Lead with the simplest design that meets the numbers, then add complexity only where the numbers or the interviewer's follow-up questions demand it. "I would start with one relational database with read replicas, and shard by user ID when writes exceed what one primary handles" is a stronger answer than starting with a sharded NoSQL cluster.

Numbers Worth Remembering

Approximate latencies, useful for reasoning about where time goes (the exact figures depend on hardware, but the orders of magnitude hold):

Main memory access: about 100 nanoseconds.
Random read from an SSD: about 100 microseconds.
Read 1 MB sequentially from memory: about 0.25 milliseconds; from an SSD: about 1 millisecond; from a spinning disk: about 20 milliseconds.
Network round trip within one data centre: about 0.5 milliseconds.
Round trip between Europe and the US east coast: about 80 to 100 milliseconds; around the world: 150 milliseconds or more.
Send 1 KB over a 1 Gbps link: about 10 microseconds.

Time and volume conversions:

A day has 86,400 seconds, so divide a daily number by about 100,000 to get a per-second rate: 1 million requests a day is about 12 per second; 100 million a day is about 1,200 per second. A month has about 2.6 million seconds; a year about 31.5 million.
Assume peak traffic is two to three times the average.
2^10 is about a thousand (KB), 2^20 about a million (MB), 2^30 about a billion (GB), 2^40 about a trillion (TB).
1 million records of 1 KB each is 1 GB. 1 billion is 1 TB.

Downtime allowed per year by availability target: 99% about 3.65 days; 99.9% about 8.8 hours; 99.99% about 53 minutes; 99.999% about 5 minutes.

Rough single-node capacities (vary widely with workload and hardware): a tuned relational database handles thousands to tens of thousands of simple queries per second; Redis around 100,000 simple operations per second per instance; a Kafka cluster millions of messages per second; a single application server a few thousand requests per second.

Terms That Are Easy to Confuse

Latency vs. throughput: how long one request takes vs. how many the system completes per second. Both matter; neither implies the other.
Availability vs. durability vs. reliability: being up and answering vs. not losing acknowledged data vs. working correctly over time.
Consistency in ACID vs. consistency in CAP: the data obeys the schema's rules vs. every read sees the latest write across replicas. Two unrelated meanings of one word.
Linearizability vs. serializability: the ordering guarantee for operations on one object across replicas vs. the isolation guarantee for transactions over many objects. Strict serializability is both.
Replication vs. sharding (partitioning): copying the same data to several nodes (for availability and reads) vs. splitting the data across nodes (for writes and size). Real systems do both.
Horizontal vs. vertical scaling: more machines vs. a bigger machine.
Load balancer vs. reverse proxy vs. API gateway: distributing traffic vs. fronting backends vs. fronting an API with auth and rate limits. One product often does all three.
Message queue vs. event stream (pub/sub): each message to one worker, deleted when done vs. a retained log that many consumers read independently and can replay.
Event-driven architecture vs. event sourcing: services communicating through events vs. storing events as the source of truth. The first does not imply the second.
Cache-aside vs. write-through: the application fills the cache lazily on reads vs. every write updates the cache and the database together.
Idempotent vs. exactly-once: an operation that is safe to repeat vs. a delivery guarantee that, in practice, is built out of at-least-once delivery plus idempotency.
Failover vs. fault tolerance: the act of switching to a standby vs. the overall property of continuing to work through failures.

For the names and history of specific technologies (Kafka, Redis, Kubernetes, PostgreSQL and the rest) and when each was created, see also the Tech Skills Glossary for Recruiters.