0 XP · 0 scenes

Glossary

Every word, in plain language.

419 technical words from the lessons. Each has a plain meaning, why it exists, and an everyday comparison.

ACID
The four promises of a database transaction: Atomicity (all or nothing), Consistency (valid state to valid state), Isolation (concurrent transactions do not interfere beyond a chosen degree) and Durability (committed data survives crashes).
Why it exists: It is the contract that lets application code stay simple while many things happen at once.
Adaptive bitrate streaming (ABR)
Streaming in which a video is available as short segments at several bitrates and the player picks, segment by segment, the quality its network and buffer can sustain.
Why it exists: It lets one video play well on any connection and keeps servers simple, since they only serve static files.
Alert
A rule that notifies a person (or a system) when a metric crosses a condition, ideally only when action is needed now.
Why it exists: Alerts turn data into response, but noisy ones make people ignore the pager.
Amdahl's law
If a fraction s of a job must run one step at a time, no number of extra workers can speed it up by more than 1/s.
Why it exists: It explains why a 64-core machine is rarely 64 times faster, and why the serial part of a system is the part to attack.
Analyzer
The pipeline that turns text into index terms: tokenising, lower-casing, removing stop words, stemming, and sometimes synonyms.
Why it exists: It decides what counts as the same word, and must be applied identically to documents and queries.
Anti-entropy
A background process in which replicas compare their data and copy whatever differs.
Why it exists: It repairs data that is never read, so replicas converge even for cold keys.
Anycast
Announcing the same IP address from many places so that each client is routed to the nearest one.
Why it exists: It spreads load and shortens the path, and a failed site simply stops being announced: it is how root DNS servers and CDNs answer from everywhere.
AOF (append-only file)
A log of every write command. On restart Redis replays it to rebuild the data. How often it is synced to disk (every write, every second, or left to the OS) sets how much you can lose.
Why it exists: It turns a memory-only store into a durable one, at the price of extra disk writes.
API gateway
A reverse proxy in front of your services that also handles API concerns: authentication, quotas, routing by URL, caching, request and response transformation, and logging.
Why it exists: It does the same cross-cutting work once at the edge instead of in every service.
Asynchronous replication
The leader confirms a write to the client as soon as it has stored it itself, and sends it to followers in the background.
Why it exists: It is fast and keeps working when a follower is slow or down, but an acknowledged write can be lost if the leader dies before it is copied.
At-least-once delivery
A guarantee that a message is delivered one or more times: it is never lost, but a failure can cause a repeat. The consumer acknowledges after processing.
Why it exists: The practical default, as long as the consumer is idempotent.
At-most-once delivery
A guarantee that a message is delivered zero or one times: it is never repeated, but a crash can lose it. Typically the consumer acknowledges before processing.
Why it exists: Cheap and simple, and right only when losing a message does not matter.
Atomic operation
A step that happens as one indivisible action: nobody can see or change things halfway through it.
Why it exists: A counter shared by many servers needs read-and-update to be atomic, otherwise two requests can read the same number and both pass.
Authentication (authN)
Proving who you are: a password, a one-time code, a key or a biometric check.
Why it exists: Everything else depends on knowing who is asking.
Authorisation (authZ)
Deciding what an authenticated identity is allowed to do or see, checked for each request and each object.
Why it exists: Knowing who someone is does not make everything they ask for permitted.
Auto-increment ID
A counter kept by one database that hands out 1, 2, 3, ... to each new row.
Why it exists: It is small, sorted and trivial to use, but it needs one authority to hand out numbers, so it becomes a bottleneck, a single point of failure and a leak of how many rows you have.
Automated rollback
A deployment system that watches health metrics of a new release against a baseline and reverts it automatically when they degrade.
Why it exists: It removes human reaction time from the damage window.
Autoscaling
Automatically adding or removing instances in response to load or a schedule, so capacity follows demand.
Why it exists: It cuts the cost of idle servers and lets a service absorb growth, provided instances can start quickly and the service is stateless.
Availability
The share of time a system is working and answering correctly, usually quoted as a percentage such as 99.9%.
Why it exists: It turns "it should rarely be down" into a number you can promise, measure and design for.
Avalanche effect
The property that changing a single input bit of a good hash changes about half of its output bits, unpredictably.
Why it exists: It means similar inputs give unrelated hashes, so you cannot nudge an input toward a chosen hash.
B-tree
A shallow, wide tree of sorted pages. Each page holds hundreds of keys and pointers to the next level.
Why it exists: It matches disk behaviour: each step reads one page, and a tree of 3–4 levels can cover hundreds of millions of rows.
Backend for frontend (BFF)
A gateway built for one kind of client (mobile, web), combining several backend calls into the shape that client needs.
Why it exists: The phone makes one small call instead of many, and each client gets exactly the data it needs.
Backlog
Work that has arrived but has not been done yet: the number of messages waiting in the queue, and how old the oldest one is.
Why it exists: A growing backlog means consumers are slower than producers, and every job is waiting longer.
Backward compatibility
A change that lets old clients keep working against the new server.
Why it exists: Servers update at once but clients update slowly, so every change must keep the old ones working.
Bandwidth-delay product
Bandwidth × round-trip time: how much data must be in flight to keep a link full.
Why it exists: A sender cannot use a fast, long link unless its window is at least this large, so high-latency links need big windows.
Base 62
A way to write numbers using 62 symbols (0-9, a-z, A-Z), so large numbers become short strings.
Why it exists: 7 base-62 characters can name 3.5 trillion items, which is why short links use it.
Batch processing
Processing a bounded set of data in one scheduled job, such as nightly aggregation or monthly billing.
Why it exists: It is simple, efficient and re-runnable, but the answer is as old as the interval between runs.
Batching
Grouping many small items into one bigger operation so that fixed costs (a network round trip, a disk flush) are paid once.
Why it exists: It raises throughput a lot, but each item waits for the batch to fill, so latency goes up.
Batching (DataLoader)
Collecting all the ids requested at one level of a query and loading them with one database call.
Why it exists: It makes calls grow with query depth instead of with the number of objects.
Binary search
Looking in a sorted list by checking the middle item and throwing away the half that cannot contain the answer, again and again.
Why it exists: It needs only about 30 steps to search a billion sorted items, versus a billion steps for a straight read. Indexes rely on this idea.
Birthday paradox
With n random values from a space of size N, a repeat becomes likely around √N values, far sooner than N.
Why it exists: It tells you how many random IDs are safe: a 64-bit random ID collides by chance after about 5 billion, a 122-bit one after about 2.7 × 10^18.
Bit
The smallest piece of information: a single switch that is either 0 or 1.
Why it exists: Computers can only reliably tell two states apart (on or off, charged or empty), so everything is built from them.
Bit rot (silent data corruption)
Stored or transmitted data changing without any error being reported, from media decay, firmware bugs, memory faults or cosmic rays.
Why it exists: Without checksums nothing notices it, and the corrupted copy can be replicated and backed up as if it were good.
Bits vs bytes
A byte is 8 bits. Network speeds are quoted in bits per second (Mbps), file sizes in bytes (MB).
Why it exists: Mixing them up is the most common estimation slip: a 100 MB/s disk is 800 Mbps, not 100.
Blast radius
The share of users, instances or regions that a change or experiment can affect if it goes wrong.
Why it exists: Keeping it small is what makes risky experiments and releases safe to attempt.
Blob (binary large object)
A large chunk of opaque bytes such as an image, video, document or backup, stored and served whole rather than queried field by field.
Why it exists: Blobs need cheap, huge, durable storage, which databases are not designed to provide.
Block address (LBA)
The drive's own numbering of its storage: block 0, block 1, block 2... The OS asks for block numbers, never for "track 17, sector 5".
Why it exists: It hides the messy physical layout. The drive decides where block 52,000 actually lives.
Blocking protocol
A protocol in which a failure can leave participants unable to make progress until something recovers. Two-phase commit blocks when the coordinator fails after participants have voted yes.
Why it exists: Blocked participants hold locks, so one crash can stall every transaction that needs the same data.
Bloom filter
A tiny structure that answers "is this key definitely not in this file?" without opening the file.
Why it exists: It lets an LSM tree skip most files on a read.
Blue-green deployment
Running two identical production environments, deploying the new version to the idle one, testing it, then switching all traffic to it. The old environment is kept for instant rollback.
Why it exists: It gives an almost instant switch and an almost instant undo, at the cost of double capacity during the release.
BM25
The standard ranking function: a term's contribution is its rarity (idf) times a saturating function of how often it appears, normalised by document length.
Why it exists: It orders matches so the most relevant come first, with two tunable parameters (k1 and b).
Bounded context
A domain-driven-design term for a part of the business inside which a model and its vocabulary are consistent, and whose edges are natural boundaries for services.
Why it exists: Boundaries drawn around business meaning tend to be stable and rarely chatty.
Broker
A Kafka server. Brokers store partitions and keep copies of each other's data.
Why it exists: If one machine dies, another copy takes over, so nothing is lost.
Buffer pool
The database's own cache of pages in RAM.
Why it exists: It makes repeated reads of hot pages almost free and lets the database batch up writes.
Bulkhead
Giving each route or dependency its own limited pool of resources so that one failing part cannot use up everything.
Why it exists: It confines damage to one feature instead of the whole system.
Burn rate
How fast the error budget is being spent relative to the pace that would use exactly the whole budget over the SLO window: error ratio divided by (1 − SLO).
Why it exists: Alerting on burn rate pages for fast outages and ignores harmless trickles.
Burst
A short spike of requests far above the average rate, such as a page firing ten API calls at once.
Why it exists: Real clients are bursty. A limiter that bans every burst annoys honest users; one that allows unlimited bursts does not protect the server.
Byte
A group of 8 bits. It can hold 256 different values (0 to 255): one letter, or one small number.
Why it exists: Memory is organised in bytes because 8 bits is a handy chunk to give a letter or a colour channel its own value.
Cache
A small, fast copy of data that lives closer to whoever needs it, so repeated reads skip the slow place.
Why it exists: Slow storage is big and cheap, fast storage is small and expensive. A cache puts the popular data in the fast place.
Cache invalidation
Making sure the cache stops returning data that has since changed in the real source.
Why it exists: A stale cache shows wrong prices or old profile photos. It is famously one of the hard problems in computing.
Cache key
The identity a cache uses to decide whether it already has a response: usually the URL plus chosen headers or cookies.
Why it exists: Two requests share a cached copy only if their keys match. Too specific a key kills the hit ratio; too loose a key serves the wrong content.
Cache line
The chunk the CPU moves between RAM and cache: usually 64 bytes. Reading one byte brings its 63 neighbours along.
Why it exists: Fetching in blocks is cheaper than fetching one byte at a time, and neighbours are likely to be needed next.
Cache stampede
A popular item expires and thousands of requests miss at the same moment, all hitting the database together.
Why it exists: The cache was protecting the database. The moment it fails, the database takes the full load and can fall over.
Canary release
Sending a small share of real traffic to a new version first, and promoting it only if it behaves.
Why it exists: It limits how many users a bad release can hurt and gives you real-world evidence before full rollout.
CAP theorem
A result (Gilbert and Lynch, 2002) that during a network partition a replicated system cannot guarantee both linearizable consistency and availability for every request.
Why it exists: It names the choice every distributed data store faces when the network splits, so you can decide it on purpose.
Capacitor
A tiny component that stores electric charge, like a very small bucket for electrons.
Why it exists: A charged capacitor can represent 1 and an empty one 0. That is the entire trick behind RAM.
Capacity planning
Forecasting demand and the resources needed over months, including headroom and the lead time to obtain more, so that limits are never hit unexpectedly.
Why it exists: Autoscaling cannot add things that take weeks to get, such as hardware, quotas or database capacity.
Cardinality and selectivity
Cardinality is how many different values a column has. A selective filter keeps only a small fraction of rows.
Why it exists: Indexes help most when a filter picks out few rows. An index on a yes/no column usually does not.
Cascading failure
A failure that makes the survivors fail too, usually because they inherit the lost server's load and cannot cope.
Why it exists: It turns a small, planned-for loss into a total outage, and it is the usual shape of big incidents.
CDN
Servers all over the world that cache copies of your files near your users.
Why it exists: Distance costs time. A cache in the user's city beats a trip across an ocean.
Change data capture (CDC)
Reading a database's transaction log to emit every row-level insert, update and delete as an ordered event stream.
Why it exists: It carries all changes, deletes included, in order, with almost no extra load on the source.
Channels and parallelism
An SSD has many flash chips on several channels and can read from many of them at once.
Why it exists: This raises throughput (many reads together) but does not shorten the delay of any single read.
Chaos engineering
The practice of running controlled experiments that inject real-world faults into a system, guided by a hypothesis about steady-state behaviour, to find weaknesses before they cause outages.
Why it exists: It replaces the belief that the system is resilient with evidence.
Checkpoint
A periodic moment when the database flushes its changed in-memory pages to the data files.
Why it exists: It limits how much log must be replayed after a crash, and lets old log files be recycled.
Checkpoint (stream processing)
A periodic, consistent snapshot of a streaming job's state together with its input positions, saved to durable storage so the job can restore and replay after a crash.
Why it exists: It makes stateful jobs recoverable without losing or double-counting events.
Checksum
A small value computed from data (a hash or CRC) that changes if the data changes, used to detect corruption.
Why it exists: It catches flipped bits and truncated or garbled data before anyone trusts it.
Choreography
Coordinating a multi-step process with no central controller: each service reacts to events and emits its own, so the flow emerges from their reactions.
Why it exists: Low coupling and simple to extend, but the overall process is invisible and hard to debug.
Circuit breaker
A switch that stops calling a dependency after repeated failures, returns an error immediately for a while, then tries again carefully.
Why it exists: It protects both the caller (no wasted waiting) and the failing service (time to recover).
Clock moving backwards
A computer's clock being set back, by NTP correction, a leap second or a bad VM restore.
Why it exists: Any ID scheme that uses time can issue the same ID twice or break its ordering when time repeats. Good generators refuse or wait.
Cold and warm cache
A cold cache is empty (just after a restart). A warm cache already holds the popular data.
Why it exists: A cold database is slow until its buffer pool refills. Everything it reads from disk makes it warmer.
Cold start
The extra latency on an invocation when the platform must create and initialise a new execution environment because no warm one is available.
Why it exists: It hits rare or bursty traffic hardest and can be reduced with smaller packages, lighter runtimes or pre-warmed capacity.
Common-cause failure
A single fault that takes down all the copies at once: a bad deploy, a shared database, a power cut in one data centre.
Why it exists: Redundancy only helps against independent failures. A shared cause is why two servers are often not twice as safe as one.
Compaction
Merging several sorted files into one, dropping overwritten and deleted entries.
Why it exists: Without it, reads would have to check too many files, and old data would waste space.
Compensating action
A new operation that semantically undoes an earlier committed one, such as a refund for a charge. It does not erase history; it adds to it.
Why it exists: It is how a saga rolls back without a database rollback, and it must be safe to retry.
Composite index
An index on several columns together, such as (city, signup_date). It is sorted by the first column, then the second inside each first value.
Why it exists: It serves filters that start with the leading columns, and can avoid sorting.
Conflict miss
A miss caused by too many addresses mapping to the same set, so they evict each other while the rest of the cache sits empty.
Why it exists: Strides that are multiples of a power of two (like 4096 bytes) hit the same set again and again.
Connection pool
A fixed set of already-open connections to a database that requests borrow and return.
Why it exists: Opening a database connection is slow, and a database can only hold so many. A pool reuses them and caps the count.
Consensus
Getting a group of machines to agree on one value or one order of commands, safely, even when some fail or messages are delayed.
Why it exists: It is the foundation for leader election, locks, and any replicated state that must never disagree.
Consistent hashing
A way to assign keys to servers so that adding or removing a server moves only a small share of the keys.
Why it exists: With hash mod N, changing N moves almost everything. Consistent hashing moves about 1/N, which is the difference between a smooth resize and an outage.
Consumer group
A team of readers that share one job. Every group gets every event; inside a group, each partition goes to one reader.
Why it exists: Email and analytics both need all orders, but each team wants to split its own work.
Consumer lag
How many events are written but not yet read by a group.
Why it exists: It tells you if a reader is keeping up. Growing lag means trouble.
Content-defined chunking
Cutting a file into chunks at positions determined by a rolling hash of the nearby bytes, so boundaries follow the content instead of fixed offsets.
Why it exists: An insertion early in a file changes only the chunks around it, so most chunks still deduplicate.
Control plane
The part of a mesh that decides and distributes configuration, identities and policy; the proxies that carry the traffic are the data plane.
Why it exists: If it fails, a well-designed data plane keeps running on its last good configuration, but changes and new certificates stop.
Cooldown (stabilisation window)
A delay after a scaling action, or a requirement that demand stays low for some time, before the scaler may remove capacity.
Why it exists: It stops the fleet from flapping in and out on noisy traffic.
Copy-on-write (COW)
A technique in which two users of the same data share one copy until one of them modifies it, at which point only the modified piece is duplicated.
Why it exists: It makes fork() instant and cheap, but memory grows with the number of pages written afterwards.
Correlation id
An identifier created when a request enters the system and copied into every event, message and log line it causes, so the whole chain can be found with one query.
Why it exists: It turns a haystack of events into a single traceable path.
Count-Min sketch
A small grid of counters with one hash function per row. Counting adds 1 in every row; the estimate is the minimum across rows. It never undercounts.
Why it exists: It gives approximate frequencies for an unlimited number of keys in fixed memory, perfect for finding heavy hitters.
Counting Bloom filter
A Bloom filter whose bits are replaced with small counters, incremented on add and decremented on remove, so that deletion is safe.
Why it exists: It allows removal without false negatives, at several times the memory of a plain filter.
Covering index
An index that already contains every column the query needs, so the database never visits the table.
Why it exists: It saves one random read per row found.
CQRS
Command-query responsibility segregation: using one model to handle commands (writes and their rules) and separate, query-shaped models to serve reads.
Why it exists: Reads become simple and fast and can scale on their own, at the cost of keeping read models in sync and tolerating a short lag.
Crash recovery
On restart, the database replays the log to redo committed changes and undo unfinished ones.
Why it exists: It is how a database promises durability even when the machine loses power mid-write.
CRC (cyclic redundancy check)
A checksum computed as the remainder of dividing the data, seen as a big binary number, by a fixed polynomial. CRC-32 is used in Ethernet, zlib and gzip.
Why it exists: It reliably catches accidental damage such as bit flips and short bursts, in hardware-fast time, but not deliberate forgery.
CRDT
A conflict-free replicated data type: a data structure designed so that replicas can merge their states in any order and always agree, without losing updates.
Why it exists: It lets available systems accept writes on both sides of a partition and still converge safely.
Credential stuffing
Trying large lists of username and password pairs leaked from other sites against a login page, hoping people reused them.
Why it exists: It compromises accounts without breaking your password storage at all.
Critical path
The chain of dependent steps that determines the total duration of a request; parallel branches matter only if they are the slowest.
Why it exists: Only speeding up the critical path makes the request faster.
Cursor pagination
Paging by asking for items after a marker (the last id or a token) instead of a numeric offset.
Why it exists: It costs the same on every page and is stable while data changes above it.
Cursor-based paging
Fetching the next page by passing the sort key of the last result (for example search_after) instead of a numeric offset.
Why it exists: The cost of a page stays constant however deep you go.
Data lake
Cheap object storage holding raw data in open file formats, with the schema applied at read time.
Why it exists: It keeps everything for any future use, at low cost, without up-front modelling.
Database index
A separate sorted structure that lets the database find rows by a column's value without reading the whole table.
Why it exists: Without it the database scans every row. With it, it jumps almost straight to the answer.
Database page
The fixed-size block (often 8 or 16 KB) that a database reads and writes. Rows live inside pages.
Why it exists: Disks and OS work in blocks, so reading one 100-byte row still reads a whole page.
DAU (daily active users)
How many distinct users use the product on a given day.
Why it exists: It is the usual starting point for estimates because everything else (requests, storage, bandwidth) is a multiple of it.
Dead-letter queue (DLQ)
A side queue where messages are moved after failing too many times, so they can be inspected or repaired.
Why it exists: It caps wasted retries and keeps failing messages safe instead of lost or looping.
Deadlock
Two or more transactions each hold a lock the other needs and wait forever; the database detects the cycle and aborts one.
Why it exists: Locking improves safety but invites deadlocks; locking rows in a consistent order avoids most.
Deduplication
Storing identical data only once, usually by splitting it into chunks identified by a content hash.
Why it exists: Saves storage and bandwidth when files repeat or change slightly.
Deep dive
Taking one or two components from the sketch and working out how they really behave: data layout, hot spots, failures.
Why it exists: It is where interviewers see depth. Pick the part that is genuinely hard for this system.
Denormalisation
Deliberately storing redundant copies of data, or precomputed results, so that reads need fewer joins.
Why it exists: It makes reads fast and simple, at the cost of fan-out writes and the risk of copies disagreeing.
Directory partitioning
A lookup table says which shard owns each key (or tenant).
Why it exists: It is the most flexible: you can move one big customer to its own shard. The cost is that the table itself must be fast, small and highly available.
Distributed hash table (DHT)
A key-value lookup service spread across many peers with no central server; each key is stored on the node(s) whose ids are closest to it.
Why it exists: It finds data in about log N hops, using only about log N routing entries per node.
Distributed lock
A shared record, kept in a store every worker can reach, saying which worker currently has the right to touch a resource. Others must wait or give up.
Why it exists: It turns a race between machines into a queue, but only as safely as the store and the timeouts behind it.
Distributed monolith
A system split into separately deployed services that are so tightly coupled they must change and release together.
Why it exists: It carries all the operational cost of microservices with none of the independence.
DNS
The Domain Name System: a worldwide directory that turns a name like example.com into an IP address.
Why it exists: Computers connect by number, people remember names. Almost every request begins with a DNS lookup, so its speed and availability affect everything.
DNS resolver
The server (usually your ISP's or a public one such as 1.1.1.1) that looks names up for you and caches the answers.
Why it exists: It does the multi-step walk (root, top-level domain, the site's own name servers) and remembers the result for the record's TTL, so most lookups never leave it.
Document store
A database that stores self-describing, JSON-like documents, each possibly with a different shape and nested data, and lets you query inside them.
Why it exists: One read returns a whole entity, and the schema can evolve without a migration.
Drive write cache
A small amount of fast memory on the drive that accepts data before it is truly written to the media.
Why it exists: It makes writes look fast. Many drives lose it on power cut unless protected by a capacitor, which is why fsync asks the drive to flush it.
Dual-write problem
The inability to update two separate systems (for example a database and a message broker) atomically, so a crash between the writes leaves them inconsistent.
Why it exists: It causes lost or phantom events and silently diverging services.
Edge server
A CDN server in a city near users that holds cached copies of your content.
Why it exists: Distance costs time, so you put copies where the people are.
Edit distance
The smallest number of single-character insertions, deletions, substitutions (and sometimes swaps) needed to turn one string into another.
Why it exists: It measures how close a typo is to a real word, and bounds how many variants a fuzzy search must consider.
ELT (extract, load, transform)
A pipeline style that loads raw data into the warehouse or lake first and transforms it there with SQL, instead of transforming it before loading (ETL).
Why it exists: It uses the warehouse's own scale for transformation and keeps the raw data for reprocessing.
End-to-end argument
The principle (Saltzer, Reed and Clark, 1984) that some functions, such as checking correctness of a transfer, can be done properly only at the endpoints, so checks inside the path are at best an optimisation.
Why it exists: It explains why per-hop checksums can still deliver corrupted data, and why applications verify their own data.
End-to-end encryption (E2EE)
Encryption in which only the sender and the recipients' devices hold the keys, so the server relays messages it cannot read.
Why it exists: The server can store and forward but never read; groups use a shared sender key so one encryption serves all members.
Epidemic (rumour-mongering) spread
Information passing from node to node the way an infection spreads: each informed node infects a few random others per round.
Why it exists: It reaches everyone in logarithmic time with no central point and tolerates lost messages and failed nodes.
Erasure coding
Splitting data into k pieces and computing m parity pieces, stored on different disks, so any k of the k + m pieces can rebuild the data.
Why it exists: It gives the durability of several copies at a fraction of the storage overhead.
Error budget
The amount of unreliability an SLO allows: (1 − SLO) of events or time. A 99.9% target over 30 days allows about 43 minutes of full outage.
Why it exists: It lets teams trade reliability against shipping speed with one agreed number.
Error-correcting code (ECC)
Extra bits stored with the data that let the drive detect and repair a few flipped bits.
Why it exists: Flash and RAM cells misread now and then. ECC fixes it, at the cost of a little time on every read.
Event log
An append-only, ordered, retained sequence of events (Kafka, Kinesis, Pulsar) that consumers read at their own positions and can replay from the start.
Why it exists: It lets new consumers bootstrap from history and lets the log be the source other stores derive from.
Event loop
One thread that waits for requests on many connections at once, runs each command to the end, and moves on to the next.
Why it exists: It avoids locks and thread switching, which is a big part of why Redis is fast. The cost: a slow command makes everyone wait.
Event sourcing
Storing every change as an immutable event in an append-only log and deriving the current state by replaying (folding) the events.
Why it exists: You get a full audit trail, time travel and the ability to build new views from history, at the cost of replay time and careful schema evolution.
Event time
The time an event actually occurred, recorded in the event, as opposed to the time it was processed.
Why it exists: Windows on event time give results that do not depend on network delays or backlogs.
Event-driven architecture (EDA)
A style in which components communicate by producing and reacting to events (facts about something that happened) rather than by calling each other directly.
Why it exists: It decouples producers from consumers and supports fan-out and replay, but makes control flow implicit and consistency eventual.
Eventual consistency
A guarantee that if no new updates are made, all replicas will eventually hold the same value.
Why it exists: It allows fast, available writes, at the price of stale reads and a merge rule for conflicts in the meantime.
Eviction policy
The rule for deciding what to throw out of a full cache. LRU drops the least recently used, LFU the least frequently used, FIFO the oldest.
Why it exists: A cache is smaller than the data behind it, so something has to leave to make room.
Expand and contract
A way to change a schema or API in compatible steps: add the new form (expand), move readers and writers over while both exist, then remove the old form (contract).
Why it exists: Every step works with the previous release, so rolling deploys and rollbacks never break.
Exponential backoff
Waiting longer after each failed attempt before retrying, typically doubling the wait each time.
Why it exists: It gives an overloaded service room to recover, instead of hammering it with instant retries.
Fail fast
Returning an error immediately when success is unlikely, instead of waiting for a slow or hung dependency.
Why it exists: An instant error frees the caller's threads and lets the user or the code react, where a long wait ties up resources and often fails anyway.
Fail static
A design in which data-plane proxies keep using their last known good configuration if the control plane becomes unreachable.
Why it exists: An outage of the control plane then stops changes, not traffic.
Failover
Promoting a replica to primary when the primary dies, and pointing clients at it.
Why it exists: Without it, one dead machine means an outage. With asynchronous replication, the new primary may be missing the last few writes.
Failure detector
A component that decides whether another node has crashed, usually from missing heartbeats or failed probes.
Why it exists: Failover, leader election and load balancing all depend on it, and its mistakes (false alarms or late alarms) set the system's reliability.
Fallback (graceful degradation)
A cheaper or simpler answer used when the real one is unavailable: a cached value, a default list, a read-only page, a queued request.
Why it exists: It lets the product keep working, at reduced quality, while a dependency is down.
False positive
The filter says an item is present when it is not. In a Bloom filter this happens when all of an absent key's bits were set by other keys.
Why it exists: It is the price of the small size; the rate is tunable and a wrong 'yes' is usually cheap to double-check.
Fan-out
One incoming request that triggers many calls to other services, and waits for all or most of them.
Why it exists: The page is only as fast as its slowest call, so the chance of hitting a slow one grows with every call you add.
Fanout
How many children each tree page points to. Bigger fanout means a shorter tree.
Why it exists: Every extra level costs another page read, so short trees are fast trees.
Feature flag
A runtime switch that turns code paths on or off for chosen users or percentages, without redeploying.
Why it exists: It separates deploying code from releasing a feature and gives an instant kill switch.
Fencing token (epoch)
A number that increases with every new leader. Storage and followers reject any request carrying an older number.
Why it exists: It lets the system refuse a deposed leader that does not know it has been replaced, without trusting its clock or its manners.
File system
The part of the OS that turns names and folders into blocks on a drive, and remembers which blocks belong to which file.
Why it exists: A drive only knows numbered blocks. The file system is why you can say "report.pdf".
Fixed window counter
A counter per clock window (for example per calendar second) that resets to zero when the window changes.
Why it exists: Very cheap: one integer per client. But a client can use the full limit at the end of one window and again at the start of the next.
Flash page and block
A flash page (about 4–16 KB) is the smallest unit you can read or write. A block is a group of hundreds of pages and is the smallest unit you can erase.
Why it exists: You cannot overwrite a page in place. You must write to an empty one and erase a whole block later.
Flash translation layer (FTL)
A table inside the SSD that maps each logical block number to wherever the data physically sits on the flash chips right now.
Why it exists: Flash cannot overwrite in place, so a rewritten block lands somewhere new. The table keeps the promise that block 52,000 is always found.
Floating gate
A small island of conductor inside a flash transistor, surrounded by insulation. Electrons pushed onto it stay trapped for years.
Why it exists: Trapped electrons change when the transistor conducts. That tiny shift is how flash remembers a bit without power.
Flying head
The read/write head rides on a cushion of air only a few nanometres above the spinning platter. It never touches it.
Why it exists: Too close and it scrapes (a head crash, which destroys data). Too far and it cannot sense the magnets.
fsync
The system call that forces buffered file data all the way onto the physical drive and waits until the drive confirms.
Why it exists: A normal write may only reach the OS's RAM cache. Without fsync, a power cut can lose data you were told was saved.
Full table scan
Reading every row in a table to find the ones that match.
Why it exists: It is correct but slow on big tables, and it is what happens when no useful index exists.
Functional requirements
What the system must do: post a message, follow a user, search a product.
Why it exists: They define the features and the API. You list them first so the design has something to serve.
Game day
A scheduled exercise in which a team deliberately triggers a failure, such as failing over a region, to check that the plan, the tooling and the people work.
Why it exists: Untested plans silently rot; rehearsal is the only way to know they still work.
Garbage collection (SSD)
The SSD's background clean-up: copy the still-valid pages out of a block, then erase the block so it can be reused.
Why it exists: Overwrites leave stale pages behind. Without clean-up the drive would run out of fresh pages.
Gossip aggregation
Computing a cluster-wide value (an average, sum, count or maximum) by having nodes repeatedly exchange and combine their local values with random peers.
Why it exists: Every node ends up knowing the global figure with no coordinator collecting data.
Gossip protocol
Each node periodically shares what it knows with a few randomly chosen peers, so information spreads through the cluster like a rumour.
Why it exists: It spreads state (including who is alive) with low, evenly spread traffic and no single point of failure.
Graph database
A database whose data model is nodes and edges with properties, optimised for following relationships.
Why it exists: Deep relationship queries (friends of friends, fraud rings) are natural to express and fast to run.
GraphQL
A query language for APIs where the client states exactly which fields it wants and gets that shape back from a single endpoint.
Why it exists: It removes over-fetching and extra round trips for varied clients, at the cost of a harder server and caching.
Gray failure
A failure that is visible to applications but not to the system's own health checks: the node looks healthy while real requests fail or crawl.
Why it exists: It is the hardest kind to detect, because the detector and the users observe different things.
gRPC
A remote-procedure-call framework from Google that sends Protocol Buffers over HTTP/2 and generates client and server code from a schema.
Why it exists: It gives compact messages, streaming and a strict typed contract for service-to-service calls.
Handshake
The opening exchange of messages that sets up a connection (TCP's three-way handshake, then TLS's key exchange).
Why it exists: Each round trip of handshake is time before the first byte of real data, which is why reusing connections and newer protocols matter.
Happens-before
The causal order of events: a happens before b if they are on the same node in that order, or a is the sending of a message and b its receipt, or through a chain of such steps. Events with no chain between them are concurrent.
Why it exists: It is the definition of 'order' that distributed systems can actually respect; it is a partial order, not a timeline.
Hash partitioning
The shard is chosen by hashing the key, so keys scatter evenly regardless of their order.
Why it exists: It spreads load well, but destroys the order of keys, so a range scan must ask every shard.
Hash ring
The hash space imagined as a circle. Servers and keys are both hashed onto it; a key belongs to the first server clockwise from it.
Why it exists: It turns "which server?" into a lookup on a sorted list, and keeps each server's range local, so changes affect only neighbours.
Hash slot
One of 16,384 buckets in Redis Cluster. A key's slot is CRC16(key) mod 16384, and every server owns a set of slots.
Why it exists: Slots make resharding cheap: move some slots and only their keys move. Multi-key commands need all keys in the same slot.
Head-of-line blocking
When one delayed or lost item makes everything behind it wait, even if the later items have already arrived.
Why it exists: TCP delivers in order, so one lost packet stalls every stream sharing the connection: a key reason HTTP/3 left TCP.
Headroom
Capacity you deliberately leave unused so that a spike or a failure does not push you past 100%.
Why it exists: Latency climbs steeply near full load, and when a server dies the others must absorb its share. Headroom is what pays for that.
Health check
A test the balancer runs to learn whether a server can handle traffic: calling a URL every few seconds (active), or watching real responses for errors (passive).
Why it exists: Without it the balancer keeps sending requests to a dead server.
Heartbeat
A tiny message sent on a schedule over an idle connection to show it is alive and keep middleboxes from closing it.
Why it exists: Without it, idle connections are cut by load balancers, and dead peers go unnoticed for a long time.
Hedged request
Sending a duplicate request to a second server if the first has not answered after a short delay, and using whichever replies first.
Why it exists: It cuts the tail for a small extra load, because it only fires for the few slow calls.
Hi/Lo (block allocation)
A server reserves a whole block of IDs (say 1,000) from a central counter in one call, then hands them out from memory.
Why it exists: It cuts trips to the central counter by the block size, at the cost of gaps when a server restarts with unused IDs.
High-level design
The first sketch: the main components (clients, servers, data stores, caches, queues) and how a request flows through them.
Why it exists: It gets agreement on the shape before any detail is spent, and shows you can think in components.
Hinted handoff
A stand-in node keeps data meant for a down node, with a note of the owner, and delivers it when the owner returns.
Why it exists: It lets writes succeed during failures and repairs the owner afterwards.
Histogram metric
A metric that counts observations in value buckets (for example how many requests took under 10 ms, 25 ms, 50 ms…).
Why it exists: Bucket counts can be summed across hosts, so fleet-wide percentiles can be estimated.
Hit and miss
A hit means the data was found in the nearest place checked. A miss means it was not, so the request goes further out.
Why it exists: Every miss pays for the slower level below. Everything in memory design is about turning misses into hits.
Hit ratio
The share of reads answered by the cache. 90% means 9 out of 10 reads skip the slow place.
Why it exists: Misses are so slow that they dominate the average. Small gains in hit ratio give big drops in average latency.
Horizontal scaling (scale out)
Adding more ordinary machines and spreading the work across them.
Why it exists: There is no hard ceiling and a dead machine costs you only a share of capacity. The price is that the work must be splittable and the machines must coordinate.
Hot key
A single key that gets a huge share of all traffic, so the one shard that owns it is overloaded while the others stay idle.
Why it exists: Spreading keys evenly does not spread traffic evenly. Viral items, global counters and popular configs create hot keys.
Hot, warm and cold tiers
Putting frequently used data on fast storage and rarely used data on cheap slow storage.
Why it exists: Most data is rarely read. Paying SSD prices for it wastes money.
Hybrid logical clock (HLC)
A clock that stores a pair (wall time, counter). It takes the larger wall time on each event and bumps the counter to break ties, so it never goes backwards, respects causality and stays close to real time.
Why it exists: Gives databases timestamps that humans can read and that never contradict cause and effect, on ordinary servers.
HyperLogLog
A probabilistic structure that estimates the number of distinct items from the longest run of leading zeros seen in hashed items, across many small registers.
Why it exists: Counts billions of distinct things in about 12 KB with around 1% error, and sketches can be merged.
Idempotent
An operation that gives the same result whether it runs once or many times.
Why it exists: Messages can arrive more than once, so handlers must tolerate repeats. An idempotency key makes a non-idempotent action safe.
Internal platform
The shared tooling and paved roads (templates, CI/CD, observability, service discovery, runtime) that make building and operating a new service cheap and consistent.
Why it exists: Without it, every service repeats the same operational work and microservices become unaffordable.
Invariant
A rule that must always hold, such as "a balance is never negative" or "a seat is sold once".
Why it exists: Invariants decide how much consistency a piece of data needs: the stronger the rule, the less freedom to be available.
Inverted index
A data structure mapping each term to a postings list: the sorted ids of the documents that contain it, often with term counts and positions.
Why it exists: It turns 'which documents contain this word?' from a scan of everything into a few list lookups and an intersection.
IOPS
Input/output operations per second: how many separate reads or writes a drive can do each second.
Why it exists: For databases making many small random reads, IOPS decides the speed, not the headline MB per second number.
Isolation level
How much concurrent transactions may see of each other's work: read uncommitted, read committed, repeatable read (snapshot), serializable.
Why it exists: Stronger levels prevent more anomalies but cost more in waiting or retries.
Jitter
A small random amount added to a wait time.
Why it exists: Without it, thousands of clients that failed together retry together in waves. Randomness spreads them out.
Jump consistent hash
A tiny function by Lamping and Veach that maps a key to one of n buckets with no memory and minimal movement when n grows.
Why it exists: It is extremely fast and perfectly balanced, but buckets can only be added or removed at the end, so it suits numbered shards, not arbitrary failures.
JWT (JSON Web Token)
A token made of a header, a payload of claims (who, role, expiry) and a signature. The signature lets anyone with the key check that the payload was not changed.
Why it exists: It lets a gateway trust a caller without a database lookup. The payload is readable by anyone, so it must hold no secrets.
Key movement
The share of keys that change owner when the set of servers changes.
Why it exists: Every moved key must be copied or becomes a cache miss, so movement is the cost of resizing.
Key salting
Adding a small random suffix to a hot key (hotkey#0 to hotkey#9) so one popular key spreads over several shards.
Why it exists: It breaks up a hotspot that hashing alone cannot, at the price of reading all the parts to see the whole key.
Lakehouse
A lake whose files are managed by a table format (Delta Lake, Iceberg, Hudi) that adds transactions, schema enforcement and versioning.
Why it exists: It aims for warehouse-style reliability on lake-style cheap, open storage.
Lambda and Kappa architectures
Lambda runs a batch path and a streaming path side by side over the same data. Kappa keeps one streaming path and reprocesses history by replaying the log.
Why it exists: Kappa avoids writing and maintaining every rule twice.
Lamport clock
A logical clock: a counter per node, incremented on each event and set to max(own, received) + 1 on receipt. It guarantees that if a happened before b then stamp(a) < stamp(b).
Why it exists: It orders events consistently with cause and effect without any real clock, but cannot say that two events were concurrent.
Last-write-wins
When copies disagree, keep the value with the latest timestamp and discard the rest.
Why it exists: It is simple and always converges, but it silently drops concurrent updates and trusts clocks that disagree.
Latency
How long one request takes from start to answer. Measured in time: nanoseconds, microseconds, milliseconds.
Why it exists: Users feel latency directly. Every step in a request adds its own wait.
Latency SLO
A target such as "99% of requests complete in under 300 ms over 30 days".
Why it exists: It says what fast enough means in terms of a percentile, so everyone can measure it and decide when to act.
Leader and follower
In single-leader replication, one node (the leader or primary) accepts all writes and sends its changes to the others (followers, replicas, secondaries), which copy them.
Why it exists: One writer means one order of changes, so copies cannot disagree about what happened first.
Leap second
A second occasionally added to or removed from UTC to keep clocks aligned with the Earth's rotation, making one minute 61 (or 59) seconds long. Different systems handle it differently (stepping back, or smearing it over hours).
Why it exists: It can make a clock repeat a second, so naive time subtraction goes negative or zero.
Lease
A time-limited grant of a lock or role that expires automatically unless the holder renews it.
Why it exists: It frees a lock held by a crashed node without anyone having to decide it is dead, at the price of waiting for the lease to run out.
Ledger
An append-only record of every movement of money, where each transaction is entered as equal debits and credits so the whole book always sums to zero.
Why it exists: It is the single source of truth for balances and the trail auditors and engineers use to find what went wrong.
Linearizability
The strongest single-object consistency: every operation appears to happen at one instant between its start and finish, and reads see the latest completed write.
Why it exists: It makes a replicated system behave like one copy, which is easy to reason about but costs latency and availability.
Little's law
Average number of requests in the system = arrival rate × average time each spends there (L = λ × W).
Why it exists: It links load, latency and concurrency for any stable system, which makes it the quickest way to size thread pools and connection pools.
Load balancer
A server or service in front of a pool of identical servers that shares incoming requests among them, and stops sending to ones that are down.
Why it exists: It adds capacity (more servers, more traffic) and availability (one server can die without an outage).
Load shedding
Deliberately refusing some requests so that the rest are served properly instead of everything slowing to a crawl.
Why it exists: A server doing 100% of its capacity for most users beats one doing 0% for all of them. Shedding keeps the survivors alive.
Locality
Programs tend to reuse the same data soon (temporal) and touch data near what they just touched (spatial).
Why it exists: Caches only work because of locality. Code that ignores it makes every read a slow miss.
Lock-renewal watchdog
A background thread that keeps extending the lock's TTL while the process is alive and working.
Why it exists: It prevents long but healthy jobs from losing their lock, but it freezes together with the process, so it cannot stop a pause from causing an overlap.
Logical shard
A small fixed unit of data (say one of 1,024 or 4,096) that is mapped onto physical machines. Adding machines moves whole logical shards, not individual keys.
Why it exists: You pick the number of logical shards once and never rehash keys: rebalancing becomes moving a few units.
Logs
Timestamped records of individual events, often text or JSON lines, written by applications and systems.
Why it exists: They hold the exact detail needed to explain one failure, at a cost that grows with traffic.
Long polling
The client sends a request and the server holds it open until it has something to say (or a timeout), then the client immediately asks again.
Why it exists: It gets near-real-time delivery over plain request/response, which works through almost any proxy.
LRU cache
A cache that, when full, discards the entry that was used least recently.
Why it exists: It keeps popular items resident and works well when recent use predicts future use, as with popular links.
LSM tree
Log-structured merge tree: writes go to memory, then flush as sorted immutable files, which are merged in the background.
Why it exists: Turns random writes into sequential ones, great for write-heavy loads.
Magnetic domain
A microscopic patch on a disk surface that can be magnetised pointing one way or the opposite way.
Why it exists: The two directions are the 0 and 1. They stay put without any power.
Materialised view
A stored copy of a query's result (a join or aggregate) that is refreshed periodically or on demand.
Why it exists: Reads of expensive queries become a simple lookup, but the data is only as fresh as the last refresh.
Memory address
The number of a byte's slot in memory: byte 0, byte 1, byte 2, and so on.
Why it exists: The CPU cannot say "give me my photo". It says "give me the byte at address 40,000". Names are an illusion built on top of addresses.
Memory controller
The part of the CPU that talks to the RAM sticks: it sends addresses and commands and collects the data.
Why it exists: RAM is a separate chip. Every miss travels through this controller and across wires to reach it.
Memtable and SSTable
The memtable is the in-memory sorted buffer of recent writes. An SSTable is a sorted, immutable file it is flushed to.
Why it exists: Sorted files are easy to search and to merge.
Merkle tree
A tree of hashes: each leaf hashes a piece of data and each parent hashes its children, up to one root hash.
Why it exists: Two datasets with equal roots are identical, and a mismatch can be narrowed to the differing pieces in a handful of comparisons.
Message queue
A buffer between a producer and a consumer. The producer writes a message (a job description) and moves on; a worker reads it later and does the work.
Why it exists: It lets you answer a user at once, absorb spikes, and keep a slow or broken service from breaking the request.
Metastable failure
A failure in which a feedback loop, such as retries or cache misses, keeps a system overloaded even after the original trigger has gone.
Why it exists: Fixing the root cause does not end the outage; operators must break the loop, usually by shedding load.
Metrics
Numbers measured over time, such as requests per second, error rate or CPU, stored as time series.
Why it exists: Tiny to store and quick to aggregate, so they power dashboards and alerts.
Microservice
A small, independently deployable service that owns one business capability and its own data, and communicates with other services over the network.
Why it exists: It lets teams build, release and scale their part without coordinating the whole system, at the cost of distributed-system complexity.
Monolith
An application built and deployed as a single unit, usually with one codebase and one database, as opposed to many separately deployed services.
Why it exists: It is the simplest architecture and the best default for small teams and new products.
Monotonic clock
A clock that only counts elapsed time and never steps backwards or jumps, unrelated to the date. Examples: CLOCK_MONOTONIC, System.nanoTime(), time.monotonic().
Why it exists: It is the right clock for measuring durations and timeouts, because NTP and leap seconds cannot disturb it.
Monotonic key
A key that only ever increases, such as an auto-increment ID or a timestamp.
Why it exists: With range partitioning every new write lands on the last shard, creating a permanent hotspot.
Monotonic reads
A guarantee that once you have seen a value, you will never later see an older one.
Why it exists: Without it, two reads served by different replicas can make data seem to go back in time.
MTBF and MTTR
Mean time between failures, and mean time to repair: how long a thing typically runs before breaking, and how long it takes to fix.
Why it exists: Availability is MTBF / (MTBF + MTTR). You can raise it by failing less often or, usually more cheaply, by recovering faster.
MTTR (mean time to recover)
The average time from the start of an incident to the service being healthy again, including detection, diagnosis and the fix or rollback.
Why it exists: It decides how many incidents a given error budget can absorb.
Multi-factor authentication (MFA)
Requiring two or more kinds of proof at login: something you know (password), have (phone, key) and are (biometric).
Why it exists: A stolen password alone is no longer enough to take over an account.
Multi-leader replication
Several nodes accept writes (often one per region) and replicate to each other.
Why it exists: Users write near home with low latency and survive a region loss, but concurrent writes to the same data must be merged.
Mutex
A lock inside a single process or machine that lets only one thread run a critical section at a time.
Why it exists: It is the simple, fast, safe cousin of the distributed lock: the operating system knows when the holder dies.
Mutual TLS (mTLS)
TLS in which both the client and the server present certificates, so each side proves who it is as well as encrypting the connection.
Why it exists: It gives every workload a cryptographic identity, so policy can say which service may call which.
MVCC
Multi-version concurrency control: updates create a new version of a row instead of overwriting, so readers see a consistent snapshot without blocking writers.
Why it exists: Readers and writers do not wait for each other. The old versions must be cleaned up later (vacuum).
N+1 query problem
Loading a list with one query, then running one more query for each item in it, instead of fetching them together.
Why it exists: The number of database calls grows with the size of the result, and a nested query makes it explode.
NAND flash
The memory chips inside an SSD. Cells trap electric charge to store bits.
Why it exists: No moving parts means fast random reads. The catch is how writes and erases work.
Network partition
A failure where the network splits nodes into groups that can talk inside each group but not between groups.
Why it exists: Nodes cannot tell a partitioned peer from a crashed one, so they must decide what to do without knowing.
Non-functional requirements
How well it must do it: how fast, how available, how consistent, for how many users, at what cost.
Why it exists: These, not the features, usually decide the architecture. Two systems with the same features but different scale or consistency look completely different.
Normal forms (1NF, 2NF, 3NF)
A ladder of rules for table design: atomic cells (1NF), every non-key column depends on the whole key (2NF), and on nothing but the key (3NF).
Why it exists: Each step removes a kind of redundancy and the anomalies it causes.
Normalisation
Organising tables so that each fact is stored once and other tables refer to it by key, to avoid redundancy and update anomalies.
Why it exists: One write changes the truth everywhere, and the data cannot contradict itself.
NoSQL
An umbrella term for databases that are not relational: key-value, document, wide-column and graph stores, typically trading joins and transactions for scale or flexibility.
Why it exists: It names what they are not; the useful question is which access pattern each is built for.
NTP (Network Time Protocol)
The protocol machines use to ask time servers for the correct time and adjust their clocks. Accuracy is a few milliseconds on a good local network and tens of milliseconds or more over the internet.
Why it exists: It keeps clocks roughly right, but never exactly: every cross-machine timestamp comparison inherits its error.
NVMe
A protocol that lets SSDs talk straight over the PCIe bus, with many parallel queues.
Why it exists: Older SATA was designed for spinning disks. NVMe removes that bottleneck and delivers far higher IOPS.
OAuth 2.0
A delegation protocol: a user lets an app access limited parts of their account at a provider through short-lived tokens, without sharing their password.
Why it exists: It is how 'sign in with' and API access to third parties work safely.
Object storage
A flat service that stores immutable objects under keys in buckets and serves them over HTTP, built for huge, cheap, durable storage rather than low-latency random updates.
Why it exists: It is where photos, videos, backups and data lakes live; S3, GCS and Azure Blob are examples.
Offset
The position number of an event inside a partition: 0, 1, 2, and so on.
Why it exists: Readers need a way to say "I have read up to here".
OLAP (online analytical processing)
The workload of a few large queries that scan and aggregate many rows across a few columns: totals, trends, comparisons.
Why it exists: Systems for it are columnar and scan-optimised, and are kept apart from the operational database.
OLTP (online transaction processing)
The workload of many small, fast reads and writes that run a business: look up a customer, place an order, update a balance.
Why it exists: Databases for it are tuned for low latency and correctness of individual transactions.
OpenID Connect (OIDC)
A thin identity layer on top of OAuth 2.0 that adds a signed ID token telling the app who the user is.
Why it exists: OAuth alone says what the app may access; OIDC says who logged in.
Optimistic concurrency
Letting commands proceed without locks and rejecting an append if the stream's version changed since the command read it.
Why it exists: No locks are held while the command thinks, so it scales, but conflicting commands must reload and retry.
Orchestration
Coordinating a multi-step process with a central coordinator (workflow engine) that sends commands to services, tracks state and handles retries and compensation.
Why it exists: The process is visible, testable and recoverable in one place, at the cost of a central component.
Order of magnitude
A number rounded to the nearest power of ten, such as thousands, millions or billions.
Why it exists: In an estimate, the right power of ten is the answer. Being off by 2× rarely changes a design; being off by 100× always does.
Origin
Your own server (or object store) where the real content lives and the CDN fetches from on a miss.
Why it exists: Everything the CDN does is to keep requests from reaching it. Its capacity is what you are protecting.
OS page cache
Free RAM that the operating system uses to remember recently read file contents.
Why it exists: Reading a file you just read is nearly free. It also means a "write" can sit in RAM for a while before reaching the disk.
Over-fetching
Receiving more data than the caller needs because the endpoint returns a fixed, complete shape.
Why it exists: It wastes bandwidth and parse time, which hurts most on mobile networks.
PACELC
An extension of CAP: if there is a Partition choose Availability or Consistency; Else, choose Latency or Consistency.
Why it exists: It reminds you that consistency has a cost on every request, not only during failures.
Page fault
When a program touches a page that is not currently in RAM, the CPU stops it and the OS loads that page from disk.
Why it exists: It is how virtual memory works, and also why running out of RAM is so painful: each fault waits for a disk read.
Page split
When a full B-tree page needs one more entry, the database splits it into two pages and updates the parent.
Why it exists: Inserts into the middle of a sorted structure are not free: they move data and write several pages.
Partition
One slice of a topic. A topic with 3 partitions is 3 notebooks written side by side.
Why it exists: One notebook can only be written so fast. Split it, and several machines share the work.
Partition key
The value Kafka hashes to choose a partition, like order_id or seller_id.
Why it exists: Events with the same key land in the same partition, so they stay in order.
Peak factor
How much busier the busiest moment is than the average: peak load ÷ average load.
Why it exists: Systems fail at the peak, not the average. A peak of 3 to 5 times the average is a common starting guess, and events can be far higher.
Peer-to-peer (P2P)
A network design in which participants act as both clients and servers, sharing their own bandwidth, storage or compute instead of relying on a central server.
Why it exists: Capacity grows with the number of users and there is no single point of failure, but you inherit churn, trust and incentive problems.
Percentile (p50, p99)
The value below which a given share of measurements fall. p50 is the median; p99 means 99% of requests were faster and 1% were slower.
Why it exists: An average hides the slow ones. Percentiles tell you what the unlucky users actually felt, and that is what they remember.
Persistent storage
Storage that keeps data with the power off: SSDs, disks, tape. Also called non-volatile or durable.
Why it exists: Anything you cannot afford to lose has to be here before you tell the user "saved".
Platter, track and sector
A platter is a spinning disk coated with magnetic material. A track is one ring on it. A sector is a small arc of a track (usually 4 KB).
Why it exists: The drive addresses data by which ring and which arc. The arm moves between rings; the spin brings the arc around.
Pointer chasing
Walking a structure where each step's address comes from the previous step's data, such as a tree or linked list.
Why it exists: The next read cannot start until the last finishes, so latencies add up and nothing can overlap or be prefetched.
Poison message
A message that can never be processed successfully, for example malformed data, and fails on every retry.
Why it exists: It wastes worker capacity forever, and in an ordered queue it blocks everything behind it.
Pre-signed URL
A URL that carries a signature made with the application's secret key, granting one specific operation on one specific object until it expires.
Why it exists: Clients upload or download directly from storage without proxying the data through your servers or receiving permanent credentials.
Preference list
The first N distinct servers found walking clockwise from a key on the ring. They hold its N replicas.
Why it exists: It gives replication for free: copies are on neighbours, and when one dies the next in line takes over without rehashing anything.
Prefetching
The CPU notices you are reading neighbouring cache lines in order and starts loading the next ones before you ask.
Why it exists: It hides RAM latency for sequential access, which is why scanning arrays is so cheap.
Producer
Any service that writes events into Kafka.
Why it exists: Someone has to report what happened, like "order 42 placed".
Program/erase cycle
One full round of writing a flash cell (program) and clearing its block (erase). Each cycle wears the insulation a little.
Why it exists: Flash cells only survive a limited number of cycles, from about 1,000 for dense cells to 100,000 for simple ones.
Projection
A read model built by reading the event stream and applying each event to a view that is shaped for a particular question.
Why it exists: Projections can be thrown away and rebuilt from history, and new ones can be added at any time.
Protocol Buffers
A compact binary format where a schema gives each field a number, and messages carry only numbers and values.
Why it exists: Smaller and faster than JSON, with clear rules for adding fields safely.
Proxy
A server that sits between two sides and passes requests along. A forward proxy acts for the client; a reverse proxy acts for the server.
Why it exists: It is a single place to filter, cache, secure and observe traffic without changing the client or the server.
Pub/sub backplane
A shared messaging layer (Redis, Kafka, NATS) that servers use to pass messages to each other so one server's event reaches users connected to other servers.
Why it exists: Users are spread over many servers, so a room's members are never all on the sender's machine.
Publish/subscribe (pub/sub)
A messaging style in which publishers send events to a topic without knowing who listens, and any number of subscribers receive them independently.
Why it exists: It decouples services in time and in knowledge of each other, and makes adding a consumer a non-event for the producer.
Purge (invalidation)
Telling a CDN to drop cached copies of a URL or tag right now, instead of waiting for the TTL.
Why it exists: It lets you cache for a long time and still publish an update immediately.
QPS (queries per second)
How many requests a system receives each second. Also called RPS (requests per second).
Why it exists: It is the first number of any estimate: it drives how many servers you need and how fast the data tier must be.
Query planner
The database component that decides how to run your query: which index to use, in which order to join.
Why it exists: The same SQL can be fast or slow depending on the plan chosen.
Queueing delay
Time a request spends waiting for a busy resource before any work starts on it.
Why it exists: Near full load the wait grows without bound, so latency rises sharply well before a system is "full".
QUIC and HTTP/3
QUIC is a transport built on UDP that gives reliable streams, built-in encryption and faster setup; HTTP/3 is HTTP running on it.
Why it exists: Streams are independent, so a lost packet delays only its own stream, and setup takes one round trip (or zero when resuming).
Quorum (R, W, N)
With N copies, a write waits for W of them and a read asks R of them. If R + W > N, every read overlaps the latest write.
Why it exists: It lets you tune consistency against latency per request instead of choosing one for the whole system.
Raft
A consensus algorithm built from leader election, log replication and safety rules, designed to be easy to understand.
Why it exists: It is the algorithm inside etcd, Consul, CockroachDB and many other systems.
RAM (DRAM)
The main memory of a computer. Each bit is a tiny capacitor that slowly leaks and gets refreshed constantly.
Why it exists: It is far cheaper per bit than CPU cache memory, so you can have gigabytes of it. It is still around 100 times slower than L1 cache.
Range partitioning
Each shard owns a contiguous slice of the key space, such as A to F, or January to March.
Why it exists: Range scans are cheap because neighbours sit together, but a skewed key space or always-growing keys overload one shard.
Rarest-first
A piece-selection rule in which a peer requests the piece that the fewest of its neighbours hold.
Why it exists: It spreads scarce pieces early, so the file stays complete in the swarm even after the original seed leaves.
Rate limiter
Code that counts how many requests a client has made recently and says no (usually HTTP 429) once they pass a set limit.
Why it exists: A server has fixed capacity. A limit stops one client from using it all, keeps costs bounded and blunts abuse.
RDB snapshot
A compact file holding the whole dataset as it was at one moment. Redis writes it every so often from a forked child process.
Why it exists: Cheap on disk and fast to restart from, but a crash loses everything since the last snapshot.
Read repair
When a read finds replicas disagreeing, the newest value is returned and written back to the stale replicas.
Why it exists: It heals data in proportion to how often it is read, at almost no extra cost.
Read-your-writes
A guarantee that after you save something, your own next reads show it, even if other people's reads may be slightly stale.
Why it exists: Without it, users resubmit forms and think saves failed. It can be given cheaply by reading your own recent writes from the leader.
Read, write and space amplification
Extra work an engine does: reading more than the answer, writing more than the change, storing more than the data.
Why it exists: Every storage engine trades these three off against each other, so none is best at everything.
Readiness probe
A check that tells the platform whether an instance is ready to receive traffic, separate from whether it is merely running.
Why it exists: It stops traffic reaching an instance that is still starting, warming up or overloaded.
Rebalancing
Moving data between shards to even out size or load, usually after adding or removing nodes.
Why it exists: It is the hidden cost of sharding: it takes disk, network and CPU from machines that are already serving users.
Reconciliation
Comparing your own records of payments with the processor's and bank's records and resolving every difference.
Why it exists: It catches lost notifications, wrong amounts and silent bugs before they grow into real losses.
Redis
An in-memory data server. It keeps data structures (strings, lists, sets, sorted sets, hashes) in RAM and answers simple commands in well under a millisecond.
Why it exists: Anything asked for thousands of times a second (sessions, counters, leaderboards, cached pages) is too hot for a disk-based database.
Redundancy
Keeping more than one copy of a component so that when one fails another carries on.
Why it exists: Failures are normal; redundancy turns "a component failed" from an outage into a non-event, as long as the copies do not fail together.
Refresh
Because each DRAM capacitor leaks, the chip reads and rewrites every row of memory every few tens of milliseconds.
Why it exists: Without it, the bits would fade to 0 within moments. It is the price of RAM's compact, cheap design.
Refresh (search index)
The operation that writes buffered documents into a new immutable segment so they become searchable; Elasticsearch does it every second by default.
Why it exists: It is why search is 'near' real time and why frequent refreshes create many small segments to merge.
Release train
A fixed schedule on which all finished changes are shipped together, such as a fortnightly release.
Why it exists: Predictable, but a single bad change can block everyone and large batches are hard to debug.
Rendezvous hashing
Also called highest-random-weight: for each key, score every server with hash(key, server) and pick the highest.
Why it exists: It needs no ring or table and moves the minimum number of keys, at the price of computing a score per server on every lookup.
Rendition
One encoded version of a video at a particular resolution and bitrate, such as 720p at 3 Mbps.
Why it exists: A video is stored as several renditions so every device and connection can play it; storage cost is the sum of them.
Replicated log
An ordered list of commands that every server holds identically; applying the same commands in the same order gives every server the same state.
Why it exists: Agreeing on the log is agreeing on the state, which turns any deterministic program into a fault-tolerant one.
Replication
Keeping copies of the same data on other machines, so one failure does not lose it.
Why it exists: A write is only as safe as its copies. But waiting for a copy to confirm (synchronous) adds a network round trip to every write.
Replication factor
How many copies of each piece of data are stored.
Why it exists: Three copies means three times the disk and three times the write traffic, a number that is easy to forget in an estimate.
Replication lag
How far behind a follower is: the time between a write on the leader and the same write being visible on the follower.
Why it exists: Reads from a lagging follower return old data, so users can fail to see what they just saved.
Request collapsing
When many requests miss for the same object at the same time, letting one go to the origin and making the rest wait for its answer.
Why it exists: It turns a stampede of thousands of identical fetches into one.
REST
An API style where each URL names a resource and standard HTTP verbs (GET, POST, PUT, DELETE) act on it, usually with JSON bodies.
Why it exists: It is simple, cacheable, and understood by every tool, which is why most public APIs use it.
Retention
How long data is kept before it is deleted or archived.
Why it exists: Storage grows with retention, so "keep it for 5 years" is a cost decision as much as a product one.
Retry
Sending a failed request again, ideally to a different instance, because many failures are brief or local.
Why it exists: Retries hide the single bad instance from users, but need limits and backoff so they do not multiply load.
Retry budget
A cap on retries as a fraction of normal traffic (for example 10% of requests), usually a token bucket filled by fresh requests and drained by retries.
Why it exists: It bounds the extra load retries can add, whatever the failure rate.
Retry storm
A feedback loop where failed requests are retried, adding load to an already overloaded server, which fails more requests, which are retried again.
Why it exists: It can keep a server down long after the original spike is over.
Round-trip time (RTT)
How long a message takes to go to the other side and the reply to come back.
Why it exists: Setting up and using a connection is counted in round trips, and distance sets a floor you cannot beat: light needs about 70 ms to cross the Atlantic and return.
Row buffer
When RAM reads, it opens a whole row of cells at once into a small buffer. Further reads from that row are quick.
Why it exists: Opening a row is the slow part. This is why reading nearby addresses is faster than jumping around memory.
Row vs columnar storage
Row stores keep each row's values together. Column stores keep each column's values together.
Why it exists: Row layout suits looking up one record. Column layout suits scanning one column across millions of rows, as in analytics.
RPM
Revolutions per minute: how fast the platters spin. Common speeds are 5,400, 7,200 and 15,000.
Why it exists: On average the data you want is half a turn away. Faster spin means shorter waits, but more heat and cost.
RPO (recovery point objective)
The most data, measured as time, that you can afford to lose in a disaster: 'the last five seconds of writes'.
Why it exists: It determines how often you must back up or how tightly you must replicate.
RTO (recovery time objective)
The longest you can afford to be down after a disaster before service is restored.
Why it exists: It determines how much standby capacity and automation you must pay for.
Saga
A long action split into a sequence of local transactions, each committed immediately, with a compensating action for each so that a failure can be unwound.
Why it exists: It gives multi-service workflows without cross-service locks, at the cost of visible intermediate states.
Salt
A random value stored with each password hash and mixed in before hashing, so identical passwords produce different hashes.
Why it exists: It defeats precomputed rainbow tables and forces an attacker to crack each user separately.
Scatter-gather
A query sent to every shard, whose partial answers are merged.
Why it exists: It works, but costs one operation per shard and is only as fast as the slowest shard, so it does not scale with shard count.
Scrubbing
A background job that reads stored data, verifies checksums and repairs any bad copy from a good replica.
Why it exists: Finds rot while other copies are still good, before several copies fail at once.
Seek time and rotational latency
On a hard disk: the time for the arm to move to the right track (seek), plus the wait for the right sector to spin under it (rotation).
Why it exists: These are mechanical delays, measured in milliseconds, and they hit every random read.
SELECT … FOR UPDATE
A locking read that takes a lock on the rows it returns, so other transactions that want to change them wait until the lock is released.
Why it exists: It makes read-then-write sequences safe for the rows you lock.
Self-preservation
A registry mode in which, when too many heartbeats go missing at once, it stops evicting instances and keeps its last known list.
Why it exists: A network fault should not look like a mass death and empty the registry.
Semi-synchronous
A middle path: wait for at least one follower (not all) to confirm.
Why it exists: One extra copy is usually enough to survive a leader crash, and a single slow follower cannot stall every write.
Sense amplifier
A circuit that detects the tiny voltage change when a RAM cell is connected to a wire, and boosts it to a clear 0 or 1.
Why it exists: A single capacitor holds so little charge that its signal must be amplified before anyone can read it. Reading it also drains it, so it is written back.
Sequence number
A counter attached to each event so a receiver can detect gaps and ask for everything after the last number it saw.
Why it exists: It makes resume after a dropped connection possible and cheap.
Sequential vs random access
Sequential means reading data stored next to each other, in order. Random means jumping around to unrelated places.
Why it exists: Disks and even SSDs and RAM are much faster at sequential access, because the hardware can prefetch and batch.
Server-Sent Events (SSE)
A browser standard for one-way push: the server keeps one HTTP response open and writes events to it, and the browser reconnects automatically.
Why it exists: It is the simplest way to stream updates to a page, with resume support built in.
Serverless (functions as a service)
A cloud model in which you deploy code that runs on demand in response to events, the provider manages and scales the servers (to zero when idle), and you pay per use.
Why it exists: You get scaling and no capacity planning, at the price of limits on time, state and control.
Service discovery
The mechanism by which services find the current network locations of other services as instances come and go.
Why it exists: Without it, every address change means editing configuration, and clients call machines that no longer exist.
Service mesh
An infrastructure layer of proxies and a control plane that handles service-to-service networking (encryption, retries, routing, metrics) without changes to application code.
Why it exists: It makes behaviour uniform across languages and teams, at the price of extra latency, resources and one more system to run.
Session
The record that says "this browser is logged in as Asha", usually found with a cookie.
Why it exists: Without one, you would have to log in on every click. Where it is stored decides whether servers can be stateless.
Set-associative cache
Each memory block may be stored in any of a few slots (ways) inside its one set, such as 2, 4 or 8 ways.
Why it exists: More ways means fewer conflicts between addresses that share a set, without checking the whole cache.
SHA-256
A cryptographic hash function that maps any data to a 256-bit fingerprint, designed so that finding two inputs with the same output, or an input for a given output, is computationally infeasible.
Why it exists: It is the standard fingerprint for content addressing, integrity of downloads, signatures and blockchains.
Shard
One slice of the data, held by one server (plus its replicas). The cluster is the set of all shards.
Why it exists: One machine cannot hold or serve everything. Sharding adds capacity by adding machines.
Shard key
The field whose value decides which shard a record lives on, such as user_id or tenant_id.
Why it exists: It is the most important decision in a sharded design: it sets load balance, which queries touch one shard, and how hard it is to change later.
Shield (tiered cache)
A layer of large caches between the edges and the origin, so all edges share one place to fetch from.
Why it exists: The origin sees each object once instead of once per edge, and a stampede is absorbed in one place.
Sidecar
A helper process or container that runs alongside each application instance and handles cross-cutting concerns; in a mesh it is the proxy all traffic passes through.
Why it exists: It adds capabilities without changing the application, but every pod pays for its memory, CPU and upgrades.
Significant figures
The digits that carry meaning. 4,300,000 to one significant figure is 4,000,000.
Why it exists: Estimates are rounded on purpose: one or two digits show you understand how rough the inputs are and make mental arithmetic possible.
Single point of failure
One component whose failure stops the whole system because nothing else can do its job.
Why it exists: Chains are only as strong as their weakest link. Finding and removing single points of failure is most of availability engineering.
SLA, SLO and error budget
An SLA is a promise to customers (with consequences). An SLO is the internal target. The error budget is how much failure the SLO still allows.
Why it exists: Without a target you cannot decide how much to spend on reliability. The budget turns it into a shared trade-off between shipping and safety.
SLC, MLC, TLC, QLC
How many bits each flash cell stores: 1, 2, 3 or 4. More bits per cell means more distinct charge levels to tell apart.
Why it exists: More bits per cell makes drives cheaper per GB, but slower, and cells wear out sooner.
SLI (service level indicator)
A measurement of service behaviour that matters to users, expressed as good events divided by valid events: for example requests that succeeded in under 300 ms divided by all requests.
Why it exists: It is the number every target, budget and alert is built on, so it has to reflect what users feel.
Sliding window
A limit measured over the last N seconds counted back from now, not over fixed clock slots. Done exactly with a log of timestamps, or approximately with two weighted counters.
Why it exists: It closes the boundary loophole of the fixed window, because the window moves with each request.
Sloppy quorum
A quorum that, when preferred nodes are unreachable, accepts writes on other healthy nodes instead of failing.
Why it exists: It keeps writes available through failures, at the price of weaker read guarantees until data is handed back.
Slow start
TCP begins by sending a small window of data and doubles it every round trip until it finds the link's limit or loses a packet.
Why it exists: Short transfers finish before the connection has sped up, so many small requests over fresh connections are slow, and reusing a warm connection is a big win.
Snapshot isolation
Each transaction reads from a consistent snapshot taken when it began; concurrent writes to the same row are detected and one transaction aborts (first committer wins).
Why it exists: It prevents dirty reads, non-repeatable reads, phantoms and lost updates, but not write skew.
Snowflake ID
A 64-bit ID built from a millisecond timestamp, a worker number and a per-millisecond sequence, invented at Twitter.
Why it exists: Each worker can mint IDs alone with no coordination, and the IDs fit a normal bigint column and sort by time.
Spatial (geo) index
A data structure that files points or regions by their location so that 'what is near here?' can be answered without checking everything; examples are grids, geohash, quadtrees, S2 and H3.
Why it exists: Without one, every nearby search scans all items; with one it touches only the few cells around the query.
Spindle motor
The motor in the middle of a hard disk that spins the platters at a steady speed (5,400 to 15,000 rpm).
Why it exists: Spin speed sets how long you wait for the right sector to come round.
Split brain
Two nodes both believe they are the leader and both accept writes.
Why it exists: The data diverges and cannot be merged safely, so some acknowledged writes must be thrown away or reconciled by hand.
Split vote
An election in which two or more candidates divide the votes so nobody gets a majority, forcing a new election.
Why it exists: It is why Raft randomises election timeouts: to make this rare.
SRAM (cache memory)
Memory made of small circuits, each holding a bit by looping two inverters back on each other. Used for CPU caches.
Why it exists: It needs no refreshing and responds almost instantly, but each bit takes about six transistors, so it is large and costly.
Stated assumption
A number or fact you choose out loud when the problem does not give one, such as 10 actions per user per day.
Why it exists: Interviews are open-ended. Saying your assumptions lets the interviewer correct you early and makes your numbers checkable.
Stateful server
A server that holds data about ongoing work in its own memory or disk: sessions, uploads in progress, open connections, a database.
Why it exists: Some state has to live somewhere. The trouble is when only one server has it: that server becomes special and cannot be swapped freely.
Stateless server
A server that keeps nothing about a user between requests. Everything it needs arrives with the request or sits in a shared store.
Why it exists: Any copy can serve any request, so you can add, remove or restart servers freely and the balancer needs no memory of who went where.
Sticky session
Making all requests from one user go to the same server, using a cookie or a hash of their address.
Why it exists: Needed when a server keeps a user's data in its own memory, but it unbalances load and loses sessions when that server dies.
Store and forward
Holding a message at the server until the recipient is reachable, then delivering it and waiting for an acknowledgement.
Why it exists: It lets chat work across offline periods and flaky networks without losing messages.
Strangler fig pattern
A migration approach that builds the replacement around the old system and routes functionality to it slice by slice until the old system can be retired.
Why it exists: Every step ships and earns value, and the project can stop at any time without loss.
Stream processing
Processing an unbounded flow of events continuously as they arrive, keeping results up to date within seconds.
Why it exists: It suits answers whose value decays quickly, such as fraud alerts and live dashboards.
Swap and page faults
When RAM runs out, the OS moves rarely used memory pages to disk (swap). Touching one later causes a page fault: the program stops while the page is read back.
Why it exists: It keeps programs alive when memory is short, at the price of speed.
Swarm
The group of peers currently sharing one particular file, trading its pieces among themselves.
Why it exists: Swarm health (how many peers, how many copies of each piece) decides how fast and how reliably the file arrives.
SWIM
A membership and failure-detection protocol in which each node probes one random peer per period, uses indirect probes to avoid false alarms, and spreads changes by piggybacking gossip on its messages.
Why it exists: It gives constant per-node cost, fast detection and low false positives, which is why it runs inside Serf, Consul and memberlist.
Sybil attack
An attack in which one party creates many fake identities to gain disproportionate influence over an open network.
Why it exists: Open peer-to-peer systems cannot trust identity counts, so they must make identities costly or constrained, or verify data independently.
Synchronous replication
The leader waits until one or more followers confirm they have the write before it acknowledges the client.
Why it exists: An acknowledged write cannot be lost by a single failure, at the price of waiting for the network and for the slowest chosen follower.
Synthetic probe
A scripted request sent on a schedule, often from outside the provider's network, to check that the service works end to end.
Why it exists: It sees failures (DNS, certificates, routing) that server-side logs never record.
Tag, index and offset
A cache splits an address into three parts: the offset (which byte inside the 64-byte line), the index (which set to look in), and the tag (which memory block that set currently holds).
Why it exists: The index picks the set directly with no searching. Only a few tags in that one set are compared, all at once, in hardware.
Tail latency
The slowest few percent of requests: p99, p99.9 and beyond.
Why it exists: Users and systems feel the tail far more than the average suggests: a page with many calls is slow if any of them is.
Target tracking
An autoscaling policy that keeps a metric (such as average CPU or requests per instance) near a target by computing desired capacity as current load divided by capacity per instance at the target.
Why it exists: It is the simplest policy that works for most workloads and is easy to reason about.
TCP
A reliable, ordered byte stream: lost packets are resent, and data arrives in the order it was sent.
Why it exists: Most of the web uses it because applications want correctness without building it themselves. The price is setup time and waiting for resends.
Term
A number that increases each time an election starts; it acts as a logical clock that tells servers whose information is newer.
Why it exists: A server that sees a higher term knows it is out of date and steps down, which stops old leaders from acting.
The nines
A shorthand for availability by counting the nines: three nines is 99.9%, four nines is 99.99%.
Why it exists: Each extra nine cuts the allowed downtime by ten. Going from 99.9% to 99.99% is the difference between about 8.8 hours a year and about 53 minutes.
Throughput
How much work gets done per second, such as MB per second or requests per second.
Why it exists: A system can have great throughput and terrible latency, or the reverse. You need to know which one your problem is about.
Thundering herd
Many clients doing the same thing at the same moment, such as all reconnecting after a restart, overwhelming the thing they depend on.
Why it exists: Synchronised retries turn a short outage into a long one. Randomised (jittered) waits break the synchrony.
Ticket server
A small, dedicated database whose only job is to hand out ID numbers, often a pair that count odd and even.
Why it exists: It keeps IDs small and strictly increasing, at the cost of one more service that must be fast and highly available.
Time-sortable ID
An ID whose leading bits are a timestamp, so sorting by ID sorts roughly by creation time.
Why it exists: New rows land at the end of the index, pagination by ID works, and no separate created-at index is needed.
Timeout
The longest a caller will wait for a reply before giving up on a call.
Why it exists: Without one, a hung dependency holds the caller's threads and connections until it fails too.
Tit-for-tat (choking)
BitTorrent's incentive rule: upload mostly to the peers that upload to you, plus one optimistic slot for a random newcomer.
Why it exists: It rewards contributors with speed and starves free-riders without any central enforcer.
TLB
A tiny cache of recent virtual-to-physical address translations inside the CPU.
Why it exists: Every memory access needs its virtual address translated. A TLB miss makes the CPU walk the page table in RAM first.
TLS certificate
A signed document that binds a domain name to a public key, issued by a certificate authority and valid for a limited time.
Why it exists: Clients use it to check they are talking to the real server, and refuse to connect once it expires.
TLS termination
Decrypting HTTPS at the edge (usually at the load balancer), so the backends receive plain traffic and do not each manage certificates.
Why it exists: Certificates and the cost of encryption are handled once, and the balancer can read the request to route it.
Token bucket
A bucket that holds up to B tokens and gains R tokens per second. Each request spends one token; with no token the request is rejected.
Why it exists: It allows short bursts (spend the saved tokens) while capping the long-run average at R. It stores only a token count and a timestamp.
Topic
A named stream of events, like "orders" or "payments".
Why it exists: Different kinds of events need their own shelf so readers can find them.
Trace sampling
Keeping only some traces to limit storage and overhead. Head sampling decides at the start of a request; tail sampling decides after it completes.
Why it exists: Tail sampling can keep every error and slow trace, which head sampling mostly misses.
Traces and spans
A trace follows one request across services as a tree of spans; each span is one operation with a start time, a duration and a link to its parent.
Why it exists: It shows where the time went and which dependency was involved.
Trade-off
A choice where improving one quality (consistency, speed, cost) worsens another, so there is no free option.
Why it exists: Naming what you gave up, and why it is acceptable here, is the clearest sign of engineering judgement.
Transactional outbox
A pattern where the event to publish is inserted into an outbox table in the same database transaction as the state change, and a separate relay publishes the rows.
Why it exists: State and event commit atomically, so no event is lost; the relay may duplicate, so consumers must be idempotent.
Transistor
A tiny electronic switch with no moving parts. A small voltage on one pin decides whether current can flow between two others.
Why it exists: Billions of them make a CPU or a memory chip. They are how electricity can remember or compute anything.
tRCD and CAS
The two waits inside RAM: tRCD is the time to open a row, CAS is the time to select a column from the open row. Each is roughly 14 ns.
Why it exists: They are fixed by the physics of sensing tiny charges, which is why RAM has not got dramatically faster in 20 years.
Trie (prefix tree)
A tree in which each step down follows one character, so all strings sharing a prefix share a path from the root.
Why it exists: It makes 'everything starting with these letters' a single subtree, the natural structure for autocomplete.
TrueTime
Google's clock API that returns an interval [earliest, latest] guaranteed to contain the true time, built from GPS receivers and atomic clocks in each data centre. The uncertainty ε is typically a few milliseconds.
Why it exists: Knowing the uncertainty exactly lets Spanner wait it out (commit wait) and order transactions globally in real time.
TTL (time to live)
A timer on a cached item. When it runs out, the item counts as expired and is fetched fresh.
Why it exists: The simplest way to stop caches from serving old data forever.
Two-phase commit (2PC)
A protocol where a coordinator asks all participants to prepare (do the work, log it, take locks, vote), then tells all of them to commit if every vote was yes or abort otherwise.
Why it exists: It makes a multi-database action atomic, at the cost of two round trips and locks held until the verdict.
UDP
A bare, connectionless way to send packets: no setup, no resends, no ordering.
Why it exists: It is fast and flexible and lets the application decide what to do about loss, which suits calls, games, DNS and QUIC.
Universal Scalability Law
A formula by Neil Gunther that predicts the throughput of n nodes from two costs: contention (waiting for something shared) and coherency (nodes keeping each other in sync).
Why it exists: It shows that scaling out is not free: with enough crosstalk, adding nodes makes the whole system slower.
Upsert
An operation that inserts a row if its key is new and updates it if it exists, in one atomic step.
Why it exists: Repeating an upsert with the same key and data gives the same result, which makes it naturally idempotent.
Utilisation
The share of a resource's capacity that is in use, such as 70% CPU busy.
Why it exists: It is the number to watch to predict queues. Latency barely moves up to about 60 to 70% and then climbs steeply.
UUID
A 128-bit identifier written as 32 hex digits. Version 4 is almost entirely random (122 random bits); version 7 starts with a timestamp.
Why it exists: Anyone can make one without asking anybody, and collisions are astronomically unlikely, which is perfect for distributed systems and offline clients.
Vector clock
A list of counters, one per node, carried with each event. Comparing two vectors shows whether one event happened before the other or whether they are concurrent.
Why it exists: It is the tool that detects conflicts, so concurrent writes can be kept and merged instead of silently overwritten.
Version vector
A small map of counters, one per node that has written a value, used to tell whether one version descends from another or the two are concurrent.
Why it exists: It detects conflicts that timestamps hide, so no concurrent write is silently lost.
Versioned (fingerprinted) file names
Putting a hash of the content in the file name (app.4f9c2.js) so a changed file gets a new URL.
Why it exists: The old URL never changes, so it can be cached for a year with no risk of staleness.
Vertical scaling (scale up)
Making one machine bigger: more CPU cores, more RAM, faster disks.
Why it exists: It needs no code changes, which makes it the fastest first fix. But there is a biggest machine you can buy, the price climbs faster than the power, and it is still one machine that can fail.
Virtual memory
A trick where each program sees its own huge private address space, and the OS maps it to real RAM (or to disk) page by page.
Why it exists: Programs do not step on each other, and the OS can move rarely used pages out to disk when RAM is short.
Virtual node
One physical server placed on the ring many times under different names (node-1#0, node-1#1, ...).
Why it exists: With one point per server the ranges are very uneven. Many points average out, so each server gets close to its fair share, and a failed server's load spreads over all the others.
Visibility timeout
After a worker receives a message, the queue hides it from other workers for this long. If the worker does not confirm in time, the message becomes visible again.
Why it exists: It is how a queue survives crashing workers without losing messages, and why a slow job can be delivered twice.
Voice-coil actuator
An electromagnet that swings a hard disk's arm back and forth, the same way a loudspeaker moves its cone.
Why it exists: It is the fastest way to move the arm, yet it is still a physical movement that takes milliseconds.
Volatile memory
Memory that forgets everything when the power goes off. RAM and CPU caches are volatile.
Why it exists: Holding a bit takes constant electrical effort. That effort is what makes it so fast, and also what makes it forgetful.
Watermark
A stream processor's estimate that no events older than a given event time will still arrive, used to decide when a window can close.
Why it exists: It sets the balance between waiting for stragglers and producing results promptly.
Wear levelling
SSDs spread erases evenly over all blocks, because each flash block survives only a limited number of erase cycles.
Why it exists: Without it, a busy spot would die quickly while the rest of the drive was fine.
WebSocket
A protocol that upgrades an HTTP connection into a persistent, two-way channel where either side can send small frames at any time.
Why it exists: It gives low-latency, low-overhead messaging in both directions, ideal for chat, games and collaboration.
Window (stream)
A finite slice of an endless stream over which an aggregate is computed: tumbling (fixed), sliding (overlapping) or session (per-user activity).
Why it exists: It is what turns 'count the events' into a question with an answer.
Worker (consumer)
A process that takes jobs from the queue, does them, and confirms completion. Many workers can share one queue.
Why it exists: Adding workers adds throughput, and a worker dying only delays its job.
Working set
The data a program is actively using over a short period, not everything it has stored.
Why it exists: If the working set fits in RAM, the app flies. If it does not, the machine starts shuffling data to disk and slows down badly.
Write amplification
When the hardware or software writes more bytes than you asked for. Ratio of physical writes to your logical writes.
Why it exists: It wears out flash, eats bandwidth and slows writes. Databases and SSDs both create it in different ways.
Write skew
An anomaly in which two concurrent transactions read overlapping data, each writes a different row, and together they violate a rule that no single transaction broke.
Why it exists: Snapshot isolation does not detect it; only serializable isolation or explicit locking and constraints do.
Write-ahead log (WAL)
An append-only file where the database records each change before touching the real data pages.
Why it exists: Appending is fast and sequential, and the log lets the database rebuild everything after a crash.
Zipf (power-law) popularity
A pattern where a few items get most of the traffic: the second most popular gets about half of the first, the third a third, and so on.
Why it exists: It is why a small cache can catch most requests, and why a small share of keys can melt a server.