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.
- Like: The terms of a bank's service.
- 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.
- Like: A water tap the player turns up or down depending on how fast the pipe is flowing.
- 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.
- Like: A smoke alarm that should not go off when you make toast.
- 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.
- Like: Nine women cannot make a baby in one month: some work is sequential.
- 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.
- Like: A librarian who decides that 'Running' and 'runs' go on the same card.
- 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.
- Like: A nightly stock count that fixes shelf records.
- 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.
- Like: A single phone number that rings the nearest branch.
- 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.
- Like: A diary where every change is written down as it happens.
- 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.
- Like: A building's security desk: checks your badge, logs you in, sends you to the right floor.
- 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.
- Like: Posting a letter and telling the client it is done before it arrives.
- 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.
- Like: Sending the letter again until you get a receipt.
- 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.
- Like: Throwing a letter in the box and not checking it arrived.
- 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.
- Like: Dropping a coin into a vending machine slot: the coin is either in or out, never half.
- 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.
- Like: Showing your ID at the door.
- 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.
- Like: The guest list that says which rooms your badge opens.
- 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.
- Like: The ticket dispenser at a deli counter.
- 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.
- Like: A circuit breaker for releases.
- 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.
- Like: A restaurant calling in extra waiters when the dining room fills.
- 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.
- Like: How often a shop's door is open when you walk up to it.
- 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.
- Like: Dropping one pebble that sets off a whole rockslide.
- 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.
- Like: A dictionary's thumb index, then a page header, then the word.
- 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.
- Like: A personal shopper who collects everything from several shops in one trip.
- 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.
- Like: The pile of unanswered mail on a desk.
- 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.
- Like: A new plug socket that still accepts the old plugs.
- 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.
- Like: The volume of water in a pipe that is full from end to end.
- 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.
- Like: Counting with a keyboard's letters and digits instead of only 0-9.
- 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.
- Like: Doing the week's laundry on Sunday.
- 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.
- Like: A bus that waits until it is full before leaving.
- 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.
- Like: Giving the shop your whole shopping list at once.
- 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.
- Like: Finding a word in a dictionary by opening it near the middle and narrowing down.
- 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.
- Like: In a room of 23 people there is a better than even chance two share a birthday.
- 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.
- Like: A light switch.
- 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.
- Like: Ink fading in an old letter while the envelope still looks perfect.
- 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.
- Like: Money in rupees versus paise.
- 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.
- Like: How many windows break if the ball goes through one.
- 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.
- Like: A parcel you store in a warehouse without opening it.
- 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.
- Like: A seat number on a ticket; the usher knows where that seat is.
- 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.
- Like: Everyone waiting for the one person who has the key and has gone home.
- 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.
- Like: A bouncer who can say for sure you are not on the list, or that you might be.
- 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.
- Like: Two stages with the same set: rehearse on one, then turn the spotlight on it.
- 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).
- Like: Marking an essay higher for hitting the topic often, but not endlessly, and not just for being long.
- 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.
- Like: A department whose words mean one thing inside it.
- 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.
- Like: Bank branches that each keep a copy of the ledger.
- 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.
- Like: A stack of recently used files on the clerk's desk.
- 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.
- Like: The watertight compartments of a ship: a leak floods one, not the vessel.
- 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.
- Like: The speed at which a fuel gauge is dropping.
- 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.
- Like: A crowd leaving a cinema all at once: fine if the doors are wide enough.
- 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.
- Like: A row of eight light switches.
- 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.
- Like: The snacks on your desk instead of walking to the shop each time.
- 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.
- Like: Updating the menu board when the kitchen changes the price.
- 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.
- Like: The label on a filing drawer.
- 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.
- Like: Buying eggs by the carton: you get 12 even if you only asked for one.
- 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.
- Like: The shop's best-selling item sells out and the whole queue rushes the warehouse.
- 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.
- Like: The canary in the coal mine: a small early warning.
- 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.
- Like: Two shops cut off from each other: either refuse sales or risk selling the same stock twice.
- 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.
- Like: A bucket that slowly leaks.
- 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.
- Like: Ordering the next size of shoes before the child outgrows the current pair.
- 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.
- Like: Searching for people by passport number (unique) versus by country (few values).
- 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.
- Like: One person leaves a rowing boat and the rest, rowing harder, tire out and quit.
- 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.
- Like: A local branch of a warehouse chain.
- 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.
- Like: A court stenographer for the database.
- 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.
- Like: More checkout lanes: more people served, but each still waits the same time.
- 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.
- Like: A fire drill with measurements.
- 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.
- Like: Saving the game, not just logging every move.
- 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.
- Like: A save point in a video game.
- 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.
- Like: The check digit at the end of a barcode.
- 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.
- Like: Dancers who each know their own steps and cue off each other.
- 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).
- Like: The fuse in your house: it cuts the circuit before the wires burn.
- 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.
- Like: Replaying the same minute of a day and writing the same receipt numbers again.
- 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.
- Like: A fridge freshly delivered versus one stocked with what you eat.
- 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.
- Like: Waiting for the shop to open its shutters for the first customer.
- 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.
- Like: Two umbrellas that both blow inside out in the same gust.
- 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.
- Like: Merging a pile of half-empty folders into one tidy folder.
- 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.
- Like: A reversal entry in an accountant's ledger instead of tearing out the page.
- 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.
- Like: A phone book sorted by surname, then first name.
- 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.
- Like: Everyone in town parking on one street.
- 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.
- Like: A set of taxis on a rank, instead of building a new car for every trip.
- 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.
- Like: A jury that must reach one verdict even if a juror falls ill.
- 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.
- Like: A circular table: a new guest takes seats only from the people next to them.
- 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.
- Like: Two teams each getting a full copy of the newspaper, then dividing the pages among members.
- 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.
- Like: The pile of unread mail on your desk.
- 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.
- Like: Cutting a rope at knots instead of at every metre.
- 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.
- Like: Air traffic control versus the planes themselves.
- 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.
- Like: Waiting a few minutes after rain stops before closing the umbrella.
- 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.
- Like: Two people sharing a notebook who photocopy a page only when one wants to scribble on it.
- 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.
- Like: A tracking number on a parcel and all its sub-parcels.
- 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.
- Like: Several noisy tally boards where you trust the lowest reading.
- 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.
- Like: A scoreboard of tallies instead of a row of on-off switches.
- 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.
- Like: A menu that lists the price right next to each dish, so you never ask the waiter.
- 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.
- Like: A kitchen that cooks from the order slip and a menu board built separately for diners to read.
- 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.
- Like: Reading yesterday's diary to rebuild what was on the whiteboard.
- 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.
- Like: A rolling remainder that changes for any slip of the pen.
- 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.
- Like: A ledger where everyone records their own entries and the totals add up whenever the books are combined.
- 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.
- Like: Trying a ring of stolen keys in every door on the street.
- 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.
- Like: The longest chain of tasks in a project plan.
- 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.
- Like: A bookmark instead of a page number in a book that gets new pages inserted.
- 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.
- Like: A bookmark instead of counting pages from the start.
- 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.
- Like: A reservoir that stores all the water before deciding what it is for.
- 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.
- Like: The index at the back of a book.
- 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.
- Like: Borrowing a whole book to read one sentence.
- 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.
- Like: The number of people who came into the shop today.
- 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.
- Like: A 'problem orders' tray where the manager looks later.
- 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.
- Like: Two cars in a narrow lane, each waiting for the other to back up.
- 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.
- Like: Photocopying one page once for everyone.
- 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.
- Like: Opening the engine of the car instead of only describing its shape.
- 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.
- Like: A cheat sheet copied from the textbook.
- 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.
- Like: A building's reception desk that tells you the floor.
- 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.
- Like: A phone book torn into pages shared among thousands of people, plus a trick for knowing whom to ask.
- 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.
- Like: A talking stick that is passed between rooms.
- 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.
- Like: A train whose carriages are separate vehicles that can only move together.
- 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.
- Like: A phone book for the internet.
- 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.
- Like: A librarian who looks things up and keeps copies of popular answers.
- 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.
- Like: A folder per customer with everything inside.
- 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.
- Like: A waiter taking your order on a notepad before it reaches the kitchen.
- 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.
- Like: Posting two letters and only one reaches the mailbox.
- 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.
- Like: A local branch of a warehouse chain.
- 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.
- Like: Counting how many keystrokes of correction a word needs.
- 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.
- Like: Unpacking the groceries in the kitchen, then cooking.
- 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.
- Like: Checking the parcel when you open it, not trusting every courier who said it looked fine.
- 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.
- Like: A letter sealed so only the addressee can open it, delivered by a postman who sees the envelope.
- 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.
- Like: A joke going around a school.
- 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.
- Like: A jigsaw where any 10 of 14 pieces show the whole picture.
- 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.
- Like: A monthly allowance you can spend on risk.
- 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.
- Like: A proofreader who corrects typos as you 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.
- Like: A diary that anyone can start reading from page one.
- 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.
- Like: A single cashier who never leaves the till: very quick per customer, but a long order holds up the whole queue.
- 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.
- Like: A bank statement of every transaction rather than only today's balance.
- 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.
- Like: The postmark date, not the date the letter was read.
- 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.
- Like: A town where people react to notices on a board instead of phoning each other.
- 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.
- Like: News spreading through a village: everyone hears, just not at the same time.
- 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.
- Like: A bookshelf with room for 10 books: which one goes back to the library?
- 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.
- Like: Building the new bridge before closing the old one.
- 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.
- Like: Knocking, then waiting a bit longer before each next knock, not banging on the door.
- 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.
- Like: Telling a customer 'we're out of that' at the door rather than after twenty minutes at the counter.
- 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.
- Like: A train that keeps running on its timetable when the signal room loses power.
- 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.
- Like: The understudy stepping on stage when the lead actor falls ill, who has not seen the last page of the script.
- 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.
- Like: A watchman deciding if the shop is closed or just quiet.
- 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.
- Like: Using the spare tyre to get to the garage.
- 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.
- Like: A guest list that sometimes lets in someone whose name merely sounds familiar.
- 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.
- Like: A group dinner that cannot start until the last guest arrives.
- 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.
- Like: A phone book with 100 sections per letter is quicker to navigate than 2 per letter.
- 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.
- Like: A light switch on a finished wiring job.
- 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.
- Like: A new lock on the door: the old key no longer turns.
- 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".
- Like: A library's catalogue: it maps titles to shelf positions.
- 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.
- Like: A turnstile that resets on the stroke of every minute, so people queue up just before it.
- 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.
- Like: A sheet of stickers on a board: you can stick new ones in free slots, but you can only clean the whole board at once.
- 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.
- Like: A cloakroom ticket: the number stays the same even if your coat moves to another rail.
- 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.
- Like: A sealed room: once you lock a few people in, they stay there.
- 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.
- Like: A hovercraft skimming a record.
- 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.
- Like: Not just posting the letter, but waiting for the signed delivery receipt.
- 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.
- Like: Reading a whole book to find one name.
- 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.
- Like: The menu of a restaurant.
- 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.
- Like: A fire drill.
- 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.
- Like: Moving the keepers into a new box so you can empty the old one.
- 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.
- Like: Pairs of students averaging their marks until everyone has the class average.
- 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.
- Like: Office news that reaches everyone by word of mouth.
- 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.
- Like: A map of who knows whom, with strings between pins.
- 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.
- Like: Ordering exactly the dishes and portions you want instead of a set menu.
- 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.
- Like: A restaurant that answers the phone but never serves the food.
- 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.
- Like: Calling a function on another machine as if it were local.
- 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.
- Like: Saying hello and agreeing the language before the conversation.
- 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.
- Like: A family tree: ancestors come before descendants, and cousins are neither before nor after each other.
- 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.
- Like: Dealing cards to players: even hands, but no player holds a suit.
- 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.
- Like: A clock face with servers at some hours; your key belongs to the next server round the dial.
- 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.
- Like: Pigeonholes in a post office, each assigned to a clerk; to add a clerk you hand over some pigeonholes.
- 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.
- Like: A slow car in a single-lane road.
- 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.
- Like: Leaving the last row of a theatre empty so a few late arrivals still fit.
- 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.
- Like: A nurse taking a pulse on a schedule, plus noticing when a patient stops answering.
- 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.
- Like: Tapping the table to show you are still there.
- 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.
- Like: Booking a second taxi when the first is late, and cancelling whichever turns up last.
- 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.
- Like: Taking a whole roll of tickets instead of one at a time.
- 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.
- Like: An architect's floor plan before the wiring diagrams.
- 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.
- Like: A neighbour who keeps your letters and gives them to you on your return.
- 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.
- Like: Sorting exam marks into ranges.
- 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.
- Like: Finding your keys in your pocket versus having to search the house.
- 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.
- Like: How often the snack you want is already on your desk.
- 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.
- Like: Adding more checkout counters to a shop instead of hiring a faster cashier.
- 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.
- Like: One checkout lane everyone queues for while the other lanes stay empty.
- 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.
- Like: Daily clothes in the wardrobe, winter coats in the attic.
- 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.
- Like: A diary with a date at the top and a small tally of entries on the same day.
- 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.
- Like: Guessing how many people were in a stadium by hearing the rarest chant someone shouted.
- 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.
- Like: Pressing a lift's call button twice: the lift still comes once.
- 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.
- Like: The shared kitchen equipment all the stalls use.
- 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.
- Like: A house rule that cannot be broken even for a minute.
- 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.
- Like: The index at the back of a book, pointing from words to pages.
- 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.
- Like: How many separate errands a driver can run in an hour, regardless of how heavy each parcel is.
- 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.
- Like: Whether roommates can see each other's half-written notes.
- 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.
- Like: People leaving a stadium over several minutes instead of in the same second.
- 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.
- Like: A numbered queue where new counters only open at the end.
- 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.
- Like: A tamper-evident wristband: you can read it, but you cannot change it without breaking the seal.
- 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.
- Like: How many people must stand up when one more chair is added.
- 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.
- Like: Splitting one very long queue into several lines.
- 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.
- Like: A lake with a harbour master.
- 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.
- Like: One chef instead of two kitchens cooking the same dish.
- 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.
- Like: Numbering the pages of a story so any scene that depends on another gets a later page.
- 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.
- Like: Whichever person pressed Save last overwrites everyone else's edits.
- 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.
- Like: How long you wait at the counter for one coffee.
- 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.
- Like: A delivery promise: 99 parcels in 100 arrive within two days.
- 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.
- Like: A head chef who writes the recipe; the other kitchens copy each change.
- 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.
- Like: A calendar that sometimes inserts an extra day and nobody agrees where.
- 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.
- Like: A parking ticket that expires by itself.
- 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.
- Like: A bank's passbook that is never erased, only added to.
- 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.
- Like: One shared notebook that everyone reads and writes in turn.
- 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.
- Like: A café that serves 10 people a minute who each stay 6 minutes needs 60 seats.
- 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).
- Like: A maitre d' directing guests to whichever waiter has free tables.
- 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.
- Like: A lifeboat that turns people away so it does not sink.
- 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.
- Like: Cooking: the ingredients you used a minute ago, and the ones next to them, are what you reach for next.
- 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.
- Like: Feeding the parking meter while you are inside the shop.
- 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.
- Like: Shipping containers: you move whole boxes between ships, not loose items.
- 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.
- Like: A ship's logbook.
- 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.
- Like: Asking someone to call you back the moment there is news.
- 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.
- Like: A desk that keeps what you used last on top and clears from the bottom.
- 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.
- Like: Collecting notes in a notepad, then filing them in sorted folders once the pad is full.
- 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.
- Like: A tiny compass needle that stays where you set it.
- 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.
- Like: A printed report instead of re-running the numbers.
- 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.
- Like: A house number on a very, very long street.
- 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.
- Like: The kitchen pass-through window between cooks and waiters.
- 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.
- Like: Today's to-do page versus finished, filed folders.
- 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.
- Like: A summary of summaries: a book's cover blurb that changes if any page changes.
- 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.
- Like: A ticket rail in a kitchen: waiters pin orders, cooks take them when ready.
- 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.
- Like: A car stuck in a rut that is deeper than the bump that pushed it in.
- 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.
- Like: The dials on a car's dashboard.
- 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.
- Like: A food stall in a market instead of one big restaurant kitchen.
- 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.
- Like: A single large house instead of a village of small ones.
- 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.
- Like: A stopwatch rather than a wall calendar.
- 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.
- Like: Everyone signing the last page of a guest book.
- 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.
- Like: A newspaper that cannot swap back to yesterday's edition mid-read.
- 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.
- Like: A car that breaks twice a year and spends two days in the garage each time.
- 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.
- Like: How long the ambulance takes, not how often accidents happen.
- 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.
- Like: A door that needs both a key and a code.
- 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.
- Like: Each branch office edits the same contract and mails changes to the others.
- 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.
- Like: A key to a single toilet.
- 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.
- Like: Two people showing ID to each other before talking.
- 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).
- Like: Keeping the old and new draft of a document so readers can finish the old one.
- 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.
- Like: Asking the shop for each item one trip at a time instead of a basket.
- 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.
- Like: A notepad where you can write in empty spaces but can only wipe a whole page at once.
- 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.
- Like: A road cut by a flood: both towns are fine but cannot reach each other.
- 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.
- Like: The restaurant's opening hours, seating and speed of service.
- 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.
- Like: Tidying a messy desk drawer by drawer.
- 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.
- Like: Writing a phone number once in the contacts app, not on every note.
- 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.
- Like: Everything in the shop that is not a hammer.
- 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.
- Like: Setting your watch by a friend's watch that you can only reach by a slow post van.
- 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.
- Like: Swapping a single-lane road for a motorway with many lanes.
- 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.
- Like: A valet key that starts the car but does not open the glove box.
- 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.
- Like: A giant left-luggage office with numbered tickets.
- 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".
- Like: A page number.
- 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.
- Like: The accountant reviewing the year's books.
- 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.
- Like: The cash register.
- 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.
- Like: The photo ID that comes with the valet key.
- 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.
- Like: Two people editing a shared doc; the second to save is told to refresh and redo.
- 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.
- Like: A conductor leading the orchestra.
- 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.
- Like: Knowing a city has about a million people, not exactly 1,043,207.
- 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.
- Like: The factory behind the shops.
- 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.
- Like: A librarian who keeps recently borrowed books on a trolley by the door.
- 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.
- Like: Being handed the whole encyclopedia when you asked for one page.
- 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.
- Like: Checking with head office before every sale, or trusting the shop's own price list.
- 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.
- Like: Realising the book you need is in storage and walking to fetch it.
- 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.
- Like: Squeezing a new name into a full line of a sorted guest list, so you copy it to two sheets.
- 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.
- Like: More checkout counters at a supermarket.
- 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.
- Like: Sorting letters into mailboxes by surname.
- 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.
- Like: A restaurant on Friday at 8 pm versus its average hour.
- 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.
- Like: A potluck where every guest brings a dish, instead of one restaurant feeding everyone.
- 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.
- Like: Class marks: knowing the median is 60 tells you nothing about the three students who failed.
- 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".
- Like: Writing in a notebook instead of on a whiteboard.
- 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.
- Like: A vinyl record: rings are tracks, a short stretch of a ring is a sector.
- 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.
- Like: A treasure hunt where each clue gives the next location.
- 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.
- Like: A bad ticket the cooks keep picking up and putting back.
- 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.
- Like: A one-use, time-limited ticket to a single locker.
- 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.
- Like: The line of people who will take over a job if the first is away.
- 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.
- Like: A waiter bringing the next course before you ask.
- Producer
- Any service that writes events into Kafka.
- Why it exists: Someone has to report what happened, like "order 42 placed".
- Like: A reporter filing a story.
- 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.
- Like: Folding a paper note: after enough folds it tears.
- 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.
- Like: A summary sheet you keep up to date from the daily ledger.
- 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.
- Like: A form where fields are printed numbers instead of long labels.
- 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.
- Like: A receptionist: callers talk to them, and they talk to the right person for you.
- 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.
- Like: The intercom between floors of a building.
- 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.
- Like: A radio station: it broadcasts once and does not know who tunes in.
- 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.
- Like: Recalling printed leaflets from every branch.
- 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.
- Like: Customers walking through the door each second.
- 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.
- Like: A GPS choosing a route.
- 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".
- Like: A motorway at 95% capacity: one brake light and everything stops.
- 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).
- Like: TCP rebuilt with lessons learned, living in user space.
- 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.
- Like: Asking three of five colleagues: any two groups of three must share someone.
- 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.
- Like: A meeting with a chair: the group elects one, and the chair's minutes are what everyone follows.
- 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.
- Like: A big desk where you spread out the papers you are working on today.
- 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.
- Like: Encyclopedia volumes: one volume per range of letters.
- 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.
- Like: Making sure the last copy of each book is copied before the library closes.
- 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.
- Like: A bouncer who lets people in at a steady pace so the room never overflows.
- 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.
- Like: A photo of the whiteboard taken every hour.
- 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.
- Like: Fixing a typo in a copy when you notice it while reading.
- 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.
- Like: Seeing your own comment appear after you post it.
- 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.
- Like: Different filing systems favour fast filing, fast finding, or small cabinets.
- 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.
- Like: A shop sign that says 'open' only once the tills are working.
- 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.
- Like: Moving house while still running the shop.
- 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.
- Like: Checking your receipts against the bank statement every month, but every day.
- 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.
- Like: A whiteboard next to your desk, instead of a filing cabinet down the corridor.
- 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.
- Like: A spare tyre and a jack.
- 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.
- Like: Re-pumping a bicycle tyre that has a slow puncture.
- 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.
- Like: Publishing the latest edition of the catalogue.
- 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.
- Like: A bus that leaves at fixed times whether or not you are ready.
- 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.
- Like: Every server bids on each key and the highest bid wins.
- 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.
- Like: The same book printed in large print, normal print and pocket size.
- 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.
- Like: A shared ledger that every branch copies line by line.
- 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.
- Like: Photocopying every page of your diary and keeping the copies in other houses.
- 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.
- Like: Keeping the same document in three different cupboards.
- 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.
- Like: A shop's price list in the branch that has not yet received the new copy.
- 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.
- Like: One person queuing for everyone's coffee.
- 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.
- Like: A library where each book has an address and you ask for it by address.
- 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.
- Like: How long you keep old bills in a drawer.
- 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.
- Like: Dialling again when the line drops.
- 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.
- Like: A petrol allowance for second attempts.
- 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.
- Like: A traffic jam made worse by everyone honking and trying the same side street.
- 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.
- Like: Shouting across a valley and waiting for the echo.
- 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.
- Like: Opening a whole drawer: grabbing a second item from it is easy.
- 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.
- Like: A list of people cards versus one sheet per attribute.
- 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.
- Like: A record player's speed setting.
- 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.
- Like: How much of the document is lost if the power cuts out: the last paragraph, or a whole afternoon.
- 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.
- Like: How long the shop stays closed after a fire.
- 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.
- Like: A booking where each step can be cancelled with a matching cancellation.
- 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.
- Like: A pinch of unique seasoning in each dish.
- 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.
- Like: Asking every branch of a bank for your balance and adding the answers.
- 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.
- Like: A caretaker who regularly checks every book and replaces damaged pages.
- 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.
- Like: A record player where you must lift the needle, move it, and wait for the right song to come round.
- 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.
- Like: Reserving a table before the meal.
- 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.
- Like: A guard who stops locking people out when half the badges suddenly fail.
- 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.
- Like: Waiting for one witness to sign, not the whole committee.
- 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.
- Like: A very good microphone for a whisper.
- 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.
- Like: Page numbers on a letter that arrives in pieces.
- 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.
- Like: Reading a book page by page versus opening it at random pages.
- 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.
- Like: A radio broadcast that the listener can retune automatically.
- 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.
- Like: Taking a taxi instead of owning a car.
- 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.
- Like: A phone directory that updates itself every time someone moves.
- 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.
- Like: A postal service that handles envelopes, tracking and locks for every office so the offices do not each build their own.
- 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.
- Like: The wristband you get at a festival gate.
- 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.
- Like: A few parking spaces per street instead of exactly one.
- 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.
- Like: A seal that cannot be copied onto a different letter.
- 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.
- Like: One branch of a library chain; each holds part of the books.
- 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.
- Like: Which drawer of a filing cabinet a document goes in: surname, date or department.
- 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.
- Like: A regional depot between the shops and the factory.
- 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.
- Like: A motorbike sidecar: attached to the main vehicle, carrying extras.
- 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.
- Like: Saying the trip takes about 3 hours, not 2 hours 47 minutes and 12 seconds.
- 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.
- Like: The one bridge into a town.
- 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.
- Like: A monthly data allowance: you may use it all, but not more.
- 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.
- Like: Telling 2 water levels apart is easy. Telling 16 apart is hard.
- 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.
- Like: The speedometer reading, not the speed limit.
- 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.
- Like: Looking at the last 60 minutes of a clock that is always moving, instead of the current hour on a calendar.
- 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.
- Like: Asking a neighbour to hold your parcel when you are out.
- 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.
- Like: A runner who must accelerate before reaching top speed.
- 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.
- Like: Working from a photograph of the database.
- 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.
- Like: A receipt number made of the time, the till number and a counter.
- 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.
- Like: A map folded into labelled squares so you open only the squares near you.
- 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.
- Like: The turntable motor.
- 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.
- Like: Two captains steering one ship in different directions.
- 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.
- Like: Two candidates each getting exactly half the votes.
- 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.
- Like: A see-saw that stays where you push it, as long as the lights are on.
- 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.
- Like: Saying "I'll assume the trip is 300 km" before computing the fuel.
- 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.
- Like: A waiter who remembers your order. Fine, until he goes home and nobody else knows what you asked for.
- 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.
- Like: A vending machine: every purchase is independent, it does not remember you.
- 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.
- Like: Always being seated at the same waiter's section.
- 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.
- Like: A post office holding your parcel until you are home.
- 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.
- Like: A vine that slowly grows around a tree.
- 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.
- Like: A cashier scanning items as they come, not at closing time.
- 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.
- Like: Stacking papers in a cupboard when the desk is full, then fetching them when needed.
- 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.
- Like: A crowd of people all helping to assemble the same jigsaw puzzle.
- 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.
- Like: A neighbourhood watch where each person checks on one random neighbour each day, and asks others to check if no answer.
- 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.
- Like: One person voting under a thousand names.
- 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.
- Like: Getting a signature at the other end before you say it was delivered.
- 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.
- Like: A mystery shopper.
- 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.
- Like: Postcode, street, house number: the postcode takes you straight to the right area.
- 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.
- Like: The one slow checkout line you always seem to join.
- 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.
- Like: A thermostat for a fleet.
- 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.
- Like: Registered post with tracking and signatures.
- 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.
- Like: The year of office of each president.
- 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.
- Like: Counting how many nines of a lottery number you got right: each one is ten times rarer.
- 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.
- Like: How many coffees the cafe sells per hour, no matter how long each customer waits.
- 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.
- Like: Everyone rushing a door the instant it opens.
- 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.
- Like: A single box office issuing all the tickets for many halls.
- 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.
- Like: Numbering a diary's pages as you write: later pages have bigger numbers.
- 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.
- Like: Hanging up when nobody answers after ten rings.
- 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.
- Like: Lending to people who lend to you, with a small bet on strangers.
- 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.
- Like: A speed-dial list of recent addresses.
- 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.
- Like: A passport with an expiry date.
- 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.
- Like: A receptionist who opens the sealed letters and hands the contents to the right desk.
- 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.
- Like: A prepaid card that tops itself up slowly: you can spend a lot at once, but not forever.
- 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.
- Like: A named notebook on a shelf.
- 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.
- Like: Reading every hundredth complaint letter, versus reading all the angry ones.
- 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.
- Like: A parcel's tracking history through every depot.
- 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.
- Like: A faster car uses more fuel.
- 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.
- Like: Writing the outgoing letter in the same ledger entry as the sale.
- 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.
- Like: A tap that another tap controls.
- 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.
- Like: Opening a drawer, then picking an item from it.
- 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.
- Like: A dictionary indexed letter by letter, like thumb tabs within thumb tabs.
- 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.
- Like: A watch that tells you not 'it is 3:00' but 'it is certainly between 2:59:59.995 and 3:00:00.005'.
- 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.
- Like: The use-by date on milk.
- 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.
- Like: A wedding officiant who asks everyone 'do you agree?' and only then says 'I now pronounce'.
- 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.
- Like: Dropping postcards in a postbox.
- 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.
- Like: A meeting that gets worse as more people are invited.
- 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.
- Like: Writing a name on the guest list: add it, or correct it if already there.
- 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.
- Like: How full the bus is.
- 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.
- Like: A name so long and random that nobody else could pick it by chance.
- 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.
- Like: Each person in a group keeping a tally of how many things they have heard from every other person.
- 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.
- Like: Each person initialling a document and counting their edits.
- 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.
- Like: A new edition number on every reprint.
- 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.
- Like: Replacing a bike with a bigger lorry: simple, but there is a biggest lorry.
- 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.
- Like: A hotel concierge who gives every guest a room number that always looks like room 1.
- 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.
- Like: Giving each person many small slices of a pie instead of one random chunk.
- 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.
- Like: A cook takes a ticket off the rail. If they vanish, it goes back after a while.
- 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.
- Like: A speaker cone that carries a tiny reading head.
- 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.
- Like: Writing on a whiteboard that wipes itself when the lights go out.
- 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.
- Like: The point after which the late guests are told the door is closed.
- 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.
- Like: Rotating your tyres.
- 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.
- Like: A phone call instead of passing notes.
- 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.
- Like: A frame cut from a long film reel.
- 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.
- Like: One of several cooks taking tickets from the same rail.
- 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.
- Like: The books open on your desk right now, not the whole library.
- 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.
- Like: Asking to fix one typo and being forced to retype the whole page.
- 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.
- Like: Two people each confirming a room is free, then booking different halves of its calendar.
- 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.
- Like: A diary of every action, written before doing it.
- 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.
- Like: A few songs on the radio are played all day; most are rarely played.