Glossary

Short, plain definitions of the terms used on this site, with links to read more.

Every term here is explained in a few plain sentences. In articles, the first mention of a term shows this definition when you point at it or tap it.

2PL (Two-phase locking)

A way to get serializable isolation by holding read and write locks until the transaction ends. Queries also lock the ranges they searched, to stop phantoms. Readers and writers block each other, and deadlocks are common. Not to be confused with two-phase commit.

ACID (Atomicity, consistency, isolation, durability)

The four guarantees of database transactions. Consistency here means the data follows its rules, unlike consistency between copies. The isolation is often weaker than serializable by default, so "ACID" does not say which anomalies remain.

Advisory lock

A lock on a number the app chooses, which the database does not tie to any row. Only code that asks for the same lock respects it, so it suits jobs such as "one worker per home".

Amplification

How much more the disk reads, writes, or stores than the data the app asked for. Read, write, and space amplification measure different costs. Compare storage engines on the same workload, since the numbers depend on it.

Analytics store

A separate store, usually with column storage, for large scans and totals over business events. It answers new questions over long history without slowing the app. Data arrives in batches or as a stream, so reports lag.

Anti-entropy

A background process that compares replicas and copies the data they are missing. It repairs keys that are never read and costs disk and network time. It must cover every replica before deletes are purged, or deleted data comes back.

AOF (Append-only file)

Redis's log of write commands, replayed on restart. Flushed once a second, it loses about a second of writes in a crash; flushed on every write, it loses none but is much slower. It is off by default.

API (Application Programming Interface)

A contract that lets one program use another program. An API says which requests a program accepts and what it returns. In system design, it usually means the network endpoints that clients and other services call.

Append-only log

A file of records that only grows at the end; old records are never changed. Appending is the cheapest write, and a newer record for a key replaces the older one. Many databases keep a log inside, for recovery or as their main storage.

Asynchronous commit

A commit that returns before its log record is flushed to disk. It cuts commit latency; a crash can lose the most recent acknowledged commits, within the WAL writer's flush window, but leaves the data consistent.

Asynchronous replication

Replication where confirming a write does not wait for followers. Writes are fast and do not depend on followers, but a confirmed write can be lost if the leader fails before a follower gets it.

Atomic commit

Committing a change on every node it touches, or on none. Two-phase commit provides it. Without it, a process that stops between two writes on two nodes leaves the change half done.

Atomic update

A single statement that computes a new value from the current one, such as subtracting from a counter. The database reads and changes the row in one step, so no other write can land in between. A condition in the statement can keep a rule, such as "never below zero".

Atomicity

The rule that a set of changes is applied fully or not at all. A failure in the middle never leaves part of the changes behind. A transaction gives it to several rows, and most stores give it to a single record.

Authorization and capture

A card payment in two steps: the authorization reserves the amount without moving money, and the capture takes it later. Cancelling an authorization moves no money, so a system can authorize first and capture only after its own records confirm the purchase. An authorization that nobody captures runs out after some days.

Autocommit

A mode in which each statement is a transaction of its own and commits when it ends. It is the default in most databases and drivers. Statements that must succeed together need an explicit transaction.

Autovacuum

The PostgreSQL background workers that vacuum and analyze tables when enough rows change. Its defaults wait too long for large tables, so busy tables need lower thresholds.

Availability zone

One of several separate failure areas in a cloud region, with one or more data centers. Zones are close enough for synchronous replication. Replicas spread over zones survive the loss of a zone, but not of the whole region.

B-tree

A storage structure that keeps sorted keys in a tree of fixed-size pages and changes them in place. A lookup follows one page per level, and the upper levels stay in memory. Leaves in key order serve ranges. It is the default index of most relational databases.

Backend (PostgreSQL)

A PostgreSQL server process that serves one client connection. Each connection costs a whole process, which is why apps reuse connections through pools.

Backfill

A job that fills a new table or field from the data that already exists. It is needed when a new query gets its own table, and it can take hours on large data.

Backup

A copy of data as it was at an earlier moment. Replicas copy a bad write within seconds, so recovering data from before it needs an older copy. A backup is proven only by a test restore.

Balanced tree

A sorted tree that keeps all paths from the root to the leaves about the same length. Lookups, inserts, and range reads stay fast as the tree grows. Red-black and AVL trees are common in memory.

BASE (Basically available, soft state, eventually consistent)

A loose label for stores that put availability and scale first and let copies disagree for a while. Many of them make only a write to one record atomic. It is not a precise guarantee, so check what the store actually provides.

Bloat

Space in tables and indexes taken by dead rows or left empty after they were removed. Some is normal. Growing bloat makes queries read more pages; fix what blocks cleanup, and rebuild when the waste stays large.

Bloom filter

A small bit array that says whether a key is definitely absent or maybe present. It never misses a key that is there, but it sometimes says "maybe" for a key that is not. A lookup by key uses it to skip files that cannot hold the key; range reads get no help.

Bounded staleness

A guarantee that a read is behind by no more than a set number of versions or seconds. It sits between linearizable and eventual reads, and lets reads come from a nearby copy while limiting how old they are.

Bridge model

Giving each tenant its own database schema or tables inside a shared database. A middle ground between the pool and the silo models: some separation per tenant at a lower cost than a database each.

BRIN (Block range index)

A tiny index that stores a summary of each range of table pages, such as the lowest and highest value. It fits huge tables whose rows are stored in the order of the indexed value, such as time.

Business transaction

A user's action that spans several requests and minutes, such as a checkout. Each step runs as a short database transaction. A claim that must last across the steps is stored in the data, not in an open transaction.

Cache

A copy of data or results that is faster to read than the original and can be rebuilt from it. It cuts latency and load on the source while it answers most reads. Losing it makes a system slower but not wrong.

Cache stampede

Many requests missing on the same key at once and all loading it from the source. It happens when a hot key expires or is deleted. Allow one load per key and serve the old value while it runs.

Cache-aside

A caching pattern where the app reads the cache, loads a miss from the source, and stores it. Only values that are read get cached, and the app can bypass a failed cache if it limits the load on the source. Every read path must handle the miss.

CAP (Consistency, availability, partition tolerance)

The rule that during a network break a replicated system either refuses some requests or lets copies disagree. It applies only while the network is split. In normal work the trade-off is between latency and consistency.

Causal consistency

The guarantee that writes which depend on each other show up in the same order on every node. Concurrent writes may show up in different orders. It can keep working during a network partition for clients that stay with a copy holding their past.

CDC (Change data capture)

Capturing the committed changes of a database, often from its log, and sending them to other systems. Derived stores follow the owner without dual writes from the app. Consumers must apply the changes of one record in order.

CDN (Content Delivery Network)

A network of servers around the world that cache content close to users. A CDN cuts latency for users and load on your servers. It suits static files and responses that many users read.

Cell

An independent copy of the whole stack that serves a subset of customers. A failure or a bad deploy stays inside one cell. A thin router sends each customer to its cell.

Checkpoint

A mark in the log from which recovery after a crash can start. The database writes changed pages to disk from time to time and records a checkpoint, so recovery does not replay the log from the beginning.

Checksum

A small value computed from data to detect whether the data has changed. The writer stores it next to the data, and the reader computes it again. A mismatch means the data is incomplete or damaged.

Circuit breaker

A guard that stops calls to a failing dependency for a while and fails fast instead. It has three states: closed (calls pass), open (calls fail fast), and half-open (a few test calls). It keeps one failure from spreading.

Citus

A PostgreSQL extension that splits tables across several servers by a distribution column. A coordinator routes each query to the servers that hold its rows.

Client-server

A model of interaction in which a client requests work or data from a server. The server handles the request and returns a response. Client and server are roles: the same component can serve one caller and make requests to another component.

Client-side caching

Keeping copies of server data in the client's memory, with the server telling the client when a copy changes. It takes reads of hot keys off the server. The client must drop its copies when it loses the connection.

CLOCK

An eviction policy that goes around the values in a circle and spares a value read since its last visit. It behaves close to LRU with less bookkeeping per read. Databases often use it for their page caches.

Clock drift

The difference in how fast two clocks run. A quartz clock that drifts by 200 parts per million, a common assumption, gains about 17 seconds a day without syncing.

Clock skew

The difference between the readings of two clocks at the same moment. It grows between syncs because clocks run at slightly different speeds, which is clock drift. An ordinary clock reading does not show it.

Clustering key

The part of a key that sorts records inside one partition. It makes range reads, such as the latest 50 messages, one read. It must be unique within the partition, or a write with the same key updates the existing record.

Co-location

Storing rows that are read or changed together on the same shard. Every related table carries the same shard key, so joins and transactions on that key stay inside one shard.

Column storage

Keeping the values of each column together instead of each record together. A query reads only the columns it needs, and columns often compress well. New rows are collected in memory and written to the columns in batches, so work on single records is less efficient.

Commit

The end of a transaction that makes all of its changes permanent at once. Other transactions see the changes only after the commit. A committed change is final: undoing it takes a new transaction that does the opposite.

Commit record

The entry in the write-ahead log that marks a transaction as committed. The transaction is committed once this entry is on disk. After a crash, the database keeps transactions that have one and removes the rest.

Commit wait

Waiting until a commit timestamp is surely in the past before showing the commit. Any transaction that starts later then gets a larger timestamp. The wait depends on the clock error, and part of it can overlap other work of the commit.

Compaction

Background work that merges data files and keeps only the latest record for each key. It frees the space taken by old and deleted records. It also competes with requests for the disk, and when writes outrun it, files pile up.

Compare-and-set

A write that succeeds only if the value is still the one the writer read. If another writer changed it first, the write does nothing, and the writer reads again and retries.

Compensating transaction

A step that undoes the business effect of an earlier step, such as a refund for a charge. It is a new change, not an erase: both stay in the records. A saga that gives up before its pivot runs compensations in reverse order.

Composite index

An index on several columns, sorted by the first column, then by the next. Put the columns compared with = first and the sort or range column last. It usually cannot help a query that uses only a later column.

Composite key

A key made of several columns, such as (workspace_id, id). An index on it sorts rows by the first column, then by the next. In a sharded table, the shard key comes first, and the rest sorts the rows inside the shard.

Concurrent writes

Writes to the same data where neither knew about the other. Time does not matter: edits hours apart on two offline devices are concurrent. With several leaders or no leader, they conflict and must be resolved.

Connection pool

A set of open connections that a client keeps and reuses. Opening a connection is slow, so services keep a pool of them to databases and other services. The pool size also limits how much load one client can put on a server.

Connection pooler

A proxy between apps and a database that shares a few database connections among many clients. PgBouncer is the common one for PostgreSQL. It keeps the number of server connections small while apps open as many as they like.

Consensus

Several nodes agreeing on one value or one order of writes, even when some fail. Crash-tolerant majority protocols need 2F + 1 voting nodes to keep working after F crashes, and progress needs timely messages. Raft, Paxos, and ZAB are common algorithms.

Consistency

The rules for which version of data a read may return. Stronger guarantees need more coordination between copies. Weaker ones allow older data and need less coordination.

Consistent hashing

Placing nodes and keys on one ring of hash values, so that a key belongs to the next node clockwise. Adding or removing a node moves only about 1/N of the keys, and every client computes placement without a central map.

Consistent prefix reads

The guarantee that readers see writes in the order they happened. One query to one replica of one log gives it. It breaks when a page combines reads taken at different points, such as different shards or two queries.

Constraint

A rule that the database checks on every write, such as a unique key or a foreign key. The database rejects a write that breaks the rule, so a bug in one service cannot break it.

Consumer group

A set of workers that share the entries of a log, each entry going to one of them. The group keeps its position in the log. In Redis it also keeps the entries delivered but not yet confirmed, so the work of a failed worker can go to another.

Coordination service

A small consensus group, such as etcd, ZooKeeper, or Consul, that other systems use for locks, leaders, and configuration. It stores small keys with linearizable writes, leases, and watches. It is meant for shared metadata; app data belongs in a database that spreads it over many groups.

Covering index

An index that holds every column a query needs. The database can answer the query from the index without reading the records. The price is a bigger index.

CQRS (Command query responsibility segregation)

Using separate models for writing data and for reading it. Reads get models shaped for them, which follow the write model with some delay.

CRDT (Conflict-free replicated data type)

A data type whose copies merge concurrent changes by a fixed rule and reach the same value. Each type has its own rule, for example what wins when an add and a remove are concurrent. Replicas converge without a central order.

Data checksums

A checksum stored in every data page so that the database detects a damaged page when it reads it. They catch corruption from disks or memory instead of returning wrong data. PostgreSQL 18 turns them on by default for new instances.

Database schema

A named group of tables inside one database, such as a schema in PostgreSQL. Tables in different schemas can share a name, so each tenant or service can get its own set of tables in one database.

Deadline

The latest time by which a whole request must finish. Each service passes the remaining time to the services it calls, so they can stop work that is no longer needed.

Deadlock

Two or more transactions that each wait for a lock another one holds, so none can go on. The database detects the cycle and aborts one transaction, which the app rolls back and retries. Taking locks in one fixed order prevents it.

Denormalization

Storing data a second time in the shape a read needs. A copied field, a counter, or a precomputed result makes a hot read cheap. Every write must also update the copy, and the copy can lag or disagree.

Derived data

Data built from other data, such as a cache, a search index, or a rollup. It can be rebuilt from its inputs while they are kept, and it needs a stated delay and a way to receive deletes.

Dirty read

A read that sees changes another transaction has not committed yet. If that transaction rolls back, the reader acted on data that never existed. Read committed and stronger levels prevent it.

Dirty write

A write that overwrites a change another transaction has not committed yet. Interleaved writes can leave rows that belong to different transactions. Every isolation level prevents it.

Distributed transaction

A transaction that changes data on several nodes and commits on all of them or on none. It needs a protocol such as two-phase commit, which adds round trips and holds locks across them.

DNS (Domain Name System)

The system that turns a domain name into an IP address. Before a client can connect to example.com, it asks DNS for the address. Answers are cached for the time set by their TTL. DNS can also spread users across servers or regions by returning different addresses.

Document model

A data model that keeps each record as one nested document, usually JSON. One request returns the whole tree. It fits records read whole and fits links between records poorly.

Dual writes

Writing the same change from the app to several stores, one after another. One write can fail after the other succeeded, and concurrent writes can arrive in different orders, which leaves the stores different without any error.

Durability

The promise that a confirmed write survives a crash or a power loss. A write is durable only after a flush, such as fsync, puts it on disk. The store chooses whether to confirm a write before or after that flush.

Election timeout

How long a follower waits without hearing from the leader before it starts an election. Raft picks it at random from a range; the paper's example is 150 to 300 ms. When a leader fails, writes pause for about this long plus the election.

Embedding

A vector of numbers that a model computes from a text or an image. Similar meanings get vectors close to each other, so a nearest-neighbor search finds similar items. Vectors from different models cannot be compared.

Escrow

Taking a quantity out of a shared count at once and keeping it in the holder's own record until it is confirmed or returned. The count always shows the worst case, so nothing is sold twice even if every hold ends in a sale. The count's row stays locked only for a short transaction, while the hold lasts minutes.

Event sourcing

Storing every change as an event and deriving the current state from the events. The full history is kept and views can be rebuilt. Deleting data and changing event formats become harder.

Eventual consistency

The promise that replicas match once writes stop and every change can arrive. It says nothing about how long that takes or what a read returns in the meantime. Session guarantees need extra routing or freshness checks.

Eviction

Dropping a value from a full cache to make room for another. A policy such as LRU or LFU picks the value, whether or not the source changed. The next read of it misses.

Exclusion constraint

A table rule that rejects a row conflicting with an existing row under chosen operators, such as overlapping dates for the same item. It stops double bookings inside the database, without races between app servers.

Exponential backoff

Waiting longer after each failed try, for example 100 ms, 200 ms, 400 ms. It gives a struggling service time to recover. Combine it with jitter and a cap on tries.

Expression index

An index on the result of a function or expression over columns, such as lower(email). A query uses it only when it contains the same expression.

Failover

Moving work to another instance when the active one fails. In replication, a follower that has every confirmed write becomes the leader. A timeout only suspects the failure, so the old leader must be fenced.

False positive

A check that says "yes" or "maybe" when the true answer is "no". A Bloom filter can give false positives but never false negatives. A false positive costs extra work, such as opening a file for nothing, but never a wrong answer.

Fencing

Stopping an old leader from writing after a new one takes over. Each new leader gets a higher number, and nodes reject writes with an older one. A timeout alone does not prove the old leader stopped.

Fencing token

A number that grows with every grant of a lock, checked by the system that receives the work. The receiver durably keeps the largest token it has accepted and, in the same atomic operation as the change, rejects older ones. A stale holder is stopped only where a newer token has already arrived.

FIFO (First In, First Out)

An order where the item that came first leaves first; as an eviction policy, it drops the value stored first. It needs less bookkeeping per read than LRU. In trace simulations it often missed about as often as LRU.

Five-minute rule

A cost rule: data read again within a break-even interval is cheaper to keep in memory than on disk. The interval comes from the price of RAM and the price of disk reads. A 2019 study found about five minutes for 4 KB pages in front of SATA SSDs.

Follower

A replica that applies the changes of a leader in the same order. It serves reads and can become the leader after a failover. Products also call it a secondary, a standby, or a read replica.

Foreign key

A column or group of columns whose values point to a unique key of a row, usually in another table. It links the two rows. The database can reject a value that points to no row and remove dependent rows on delete.

Freezing

Marking old rows as visible to every transaction, so their transaction IDs can be used again. PostgreSQL vacuuming does it; if it falls behind, the database stops taking writes.

Functional partitioning

Moving whole features or groups of tables to their own databases. Each database gets smaller and can be tuned for its load, but joins and transactions no longer cross them. It cannot split one large table.

Generated column

A column whose value the database computes from other columns of the same row. A stored one is computed on every insert and update and kept like a normal column, so it can be indexed and constrained.

GeoDNS

DNS that answers with different addresses depending on where the client is. It picks a region from an estimate of where the user is. Cached answers delay a change until they expire, and open connections must reconnect.

GIN (Generalized inverted index)

An index that maps each element of a value, such as a word or a JSON key, to the rows that contain it. It answers "contains" queries on documents, arrays, and text, and makes writes slower.

GiST (Generalized search tree)

A PostgreSQL index for values that overlap or lie near each other, such as ranges, shapes, and points. It answers "overlaps" and "nearest" queries and enforces exclusion constraints.

Global index

A secondary index over all shards, itself sharded by the indexed value. A lookup reads one index shard. Every write also touches the index shard, so the index either slows writes or lags behind them.

Graph model

A data model of vertices and the edges between them, both with properties. Queries follow edges, so paths of unknown length are easy to express. In SQL each step of a path is a join.

GraphQL

An API style where the client sends a query that names exactly the fields it needs. There is usually one endpoint, and the response has the shape of the query. It avoids over-fetching and many round trips, but caching and rate limiting are harder.

Group commit

Making several writes durable with one shared flush. The store collects the writes that arrive within a few milliseconds and flushes them together. It can then wait for the disk before saying "ok" without paying a flush for each write.

gRPC

A framework for calling functions on another service, with binary messages over HTTP/2. You describe the calls in a .proto file and generate client and server code from it. Messages are small and fast to parse. It is common for service-to-service calls, but browsers cannot call it directly.

Happens-before

The order of events in which one event could have affected another: earlier in the same process, or through a message. Events where neither happens before the other are concurrent, whatever the clocks say.

Hash index

An index that maps each key to the place of its record through a hash map. It answers lookups by exact key in one step, but it keeps no order, so it cannot return a range of keys. An in-memory hash index needs all keys to fit in RAM.

Hash join

A join that builds a hash table from one input in memory and probes it with the other. It is often useful for large inputs joined by equality.

Hash map

An in-memory structure that finds a value by its key in constant time. It keeps no order, so it finds one key but cannot return a range of keys.

Hash partitioning

Placing each row on a shard by a hash of its key. Neighboring keys land on different shards, so writes spread evenly whatever order keys arrive in. Key order is lost: a range read over the hashed key asks every shard.

Hash tag

The part of a Redis key in braces that alone decides the key's hash slot. Keys with the same tag land on the same server, so one command or script can use them together. A busy tag becomes a hot spot.

Health check

A regular probe that tells whether a server can take traffic. Load balancers remove servers that fail several checks in a row and add them back after several successes.

Read more: Networking: Adding servers

Heap (table)

A table stored as pages of rows in no particular order. PostgreSQL B-tree indexes point to a row's place in the heap, so an update that is not HOT needs new index entries.

Hedged request

A second copy of a slow request, sent to another replica; the first answer wins. It cuts tail latency for a small share of extra load, because the second copy goes out only after a short wait.

Hinted handoff

Storing writes for a replica that is down on another node and passing them on when it returns. It covers short outages. Data held only as hints is not readable from the key's own replicas.

Hit ratio

The share of requests a cache answers without going to the source. It sets how much load and latency a cache removes. It depends on the number of keys, the memory, and how often values change.

HNSW (Hierarchical navigable small world)

An approximate vector index built as a layered graph of nearby vectors. It is fast with good recall, but takes memory and time to build.

Hold

A claim on a resource, stored in its row as a state with an expiry time. Short transactions set and check it, and an expired hold counts as free. The final transaction checks the hold again.

Horizontal scaling

Handling more load by adding machines instead of buying a bigger one. Stateless servers scale this way easily. Data scales this way through sharding, which needs a key, routing, and moving data.

Hot key

One key value that gets more traffic than a whole shard can serve. Adding or moving shards does not help, since the key lives on one shard. Cache it for reads, or salt it for writes.

Hot row

A row that many transactions write at once, so they wait for its lock one by one. Throughput drops to one transaction at a time. Splitting the row into many rows that writers take independently removes the queue.

Hot shard

A shard that gets far more load than the others. It runs out of capacity while other shards sit idle. Causes include a large tenant or keys written in order. One key that alone needs more than a shard is a hot key.

HOT update (Heap-only tuple update)

A PostgreSQL update that adds no entries to indexes that point to rows: no column they use changes, and the new version fits on the same page. Keeping updates HOT saves index writes and WAL. Since PostgreSQL 16, a BRIN index does not prevent it.

HTTP (Hypertext Transfer Protocol)

The request-response protocol of the web. A client sends a request with a method (GET, POST, …), a path, and headers. The server sends back a status code, headers, and a body. Most public APIs run on HTTP.

HTTP/2

A newer version of HTTP that sends many requests over one connection at the same time. HTTP/2 splits requests into streams on one TCP connection and compresses headers. A lost TCP packet still stops all streams until it is resent.

HTTP/3

The version of HTTP that runs on QUIC instead of TCP. HTTP/3 keeps the many-streams model of HTTP/2, but a lost packet holds up only the streams whose data it carried. It also sets up connections faster.

HTTPS (HTTP Secure)

HTTP sent over an encrypted TLS connection. HTTPS is the same HTTP, but TLS encrypts it and proves the server is who it claims to be. Today almost all web traffic uses HTTPS.

Hybrid logical clock

A timestamp made of physical time plus a counter, which never goes back and stays close to real time. Timestamps respect cause, never go back, and stay close to real time, but do not prove real-time order. A database adds isolation and rules for clock skew on top.

HyperLogLog

A structure that estimates how many distinct items it has seen, in a small fixed amount of memory. In Redis it takes at most 12 KB per key with a standard error of 0.81%. Estimates of several periods can be merged without counting a repeat visitor twice.

Idempotency key

A unique ID the client attaches to a request, so the server can recognize a retry of it. If the same key comes again, the server returns the saved result instead of doing the work twice. Used for payments and orders.

In doubt

The state of a two-phase commit participant that voted yes but has not learned the decision. It must wait and keep its locks until the coordinator answers, since aborting on its own could break atomicity.

Index

Extra data, built from the records, that finds a record without a full scan. An index speeds up reads, but it takes space and every write must update it too. So a database indexes only what its queries need.

Index-only scan

A read that answers a query from an index, visiting the table only for pages not known to be visible to everyone. It needs every requested column in the index; vacuuming keeps the map of all-visible pages current.

Instance (PostgreSQL)

One PostgreSQL server: a main process with its memory and data directory, holding one or more databases. Its databases share memory, processes, and one WAL, so standbys and physical backups copy all of them together.

Invalidation

Removing a cached copy because the original changed. The usual way is to delete the key after the write commits, so the next read loads the new value. Keep a TTL as well, since a delete can lose a race.

Inventory

The count of units of one type that exist and that are taken, per period, which a sale checks and changes. One row per unit type and period, such as a room type and a night, holds both numbers. A sale raises the taken count with an atomic update that keeps it within the total.

Inverted index

An index from each word to the list of records that contain it. It finds records by words inside text, which a B-tree index cannot do.

IP address (Internet Protocol address)

The number that identifies a device on a network. IP, the Internet Protocol, delivers packets to these addresses with no guarantees; TCP and UDP run on top of it. DNS maps names to IP addresses.

Isolation

How much concurrent transactions are kept from seeing or overwriting each other's work. Each level, from read committed to serializable, blocks a different set of anomalies. Stronger levels cost waits or retries.

IVF (Inverted file index)

An approximate vector index that groups vectors into clusters and searches only the nearest clusters. It builds faster and uses less memory than HNSW, with lower speed or recall.

Jitter

A random extra wait added before a retry. Without jitter, many clients retry at the same moment and overload the service again.

Join

A query operation that combines rows of tables by a matching condition, usually on keys. It turns stored IDs back into the data they point to, such as an author's name for a post. Every join is work on each read.

JSON (JavaScript Object Notation)

A text format for nested data: objects with named fields, lists, strings, numbers, and booleans. Document stores keep records as JSON or a binary form of it, and relational databases have JSON columns.

JSONB

A PostgreSQL column type that stores JSON in a parsed binary form that can be queried and indexed. It suits attributes that differ from record to record, next to typed columns for the core fields.

Jump consistent hash

A short function that maps a key to one of N numbered shards with no stored state. Growing N moves only about 1/N of the keys. Shards are numbered in order, so only the last one can be removed.

Keep-alive

Keeping a connection open after a response, so the next request can reuse it. Reusing a connection skips the TCP and TLS handshakes. Clients and servers close idle connections after a timeout.

Key-value model

A data model with three operations: get, put, and delete a value by its full key. The store does not look inside the value. In return, the data is easy to spread across machines.

L4 / L7

Network layers: L4 is the transport layer (TCP, UDP), L7 is the application layer (HTTP). An L4 load balancer routes connections. An L7 load balancer reads each HTTP request and can route by path or header.

Read more: Networking: Adding servers

Lamport clock

A counter that gives every event a number, so that an event that happens before another gets a smaller one. Each message carries the counter, and a receiver jumps past it. The pair (counter, process ID) gives one sort order that respects cause, but cannot detect concurrent events.

Last write wins

Resolving a conflict by keeping the write with the latest timestamp. Replicas converge, but the other write is lost without an error, and clocks that differ can make an older write win.

Leader

The replica that accepts writes and decides their order. It sends each change to the followers through the replication log. Products also call it the primary or the source.

Leaderless replication

Replication where any replica accepts writes and clients write to and read from several replicas. No leader promotion is needed when a replica fails. Reads and writes go on while enough replicas answer; concurrent writes still need a conflict rule.

Lease

A right, such as a lock, that lasts a set time and must be renewed. When the holder stops renewing it, the lease runs out and another holder can take over. A lease that guards outside work needs a fencing token or work that is safe to repeat, since a paused holder may still act.

Least connections

Sending each new connection to the server with the fewest open connections. Good for long-lived connections, where the number of open connections shows the load better than the number of requests.

Leveled compaction

A compaction strategy that keeps files in levels where, apart from newly flushed files, the files of one level do not overlap in keys. A lookup by key checks the newly flushed files and at most one file in each other level. Data takes less space than with size-tiered compaction, but it is rewritten more often.

LFU (Least Frequently Used)

An eviction policy that drops the value read least often. It keeps steady favorites through a scan. Its counts must decay, or values popular yesterday stay too long.

Linearizability

The guarantee that all reads and writes fit one order on a single copy, matching real time. Once a write finishes, every later read returns it or a newer value. It needs coordination between copies, so it costs latency and makes some nodes refuse requests during a network partition.

Load balancer

A component that spreads incoming traffic across several servers. It also stops sending traffic to servers that fail health checks, so clients see one stable address.

Read more: Networking: Adding servers

Local cache

A cache in the memory of each app server. Reads skip the network, which takes load off a hot key. Each server holds its own copy; the TTL limits local reuse, and the remote copy may already be old.

Local index

A secondary index on each shard that covers only that shard's rows. A write updates one shard. A query without the shard key has to ask every shard.

Locality

Keeping data that is used together close together in storage. One request then returns all of it with fewer lookups. It helps only when the reader needs most of the stored data.

Lock

A mark that reserves a row or a range of rows for one transaction and makes conflicting transactions wait. A write takes an exclusive lock on its row until the transaction ends, and readers can share a shared lock. Locks prevent conflicting writes but cause waits and deadlocks.

Lock timeout

The longest time a transaction waits for a lock before it fails. Too short aborts transactions that were only slow; too long keeps users waiting.

Log position

A point in a replication log, such as the number of the last change a replica applied. A new follower starts from the position of its snapshot. The gap between the leader and a follower shows how much log is still to apply.

Logical decoding

Turning the WAL of PostgreSQL into a stream of row changes in commit order. Logical replication and CDC tools read changes this way.

Logical replication

Replication that sends changed rows instead of statements or pages. Replicas can run different compatible versions, which allows an upgrade with a short switch, and other systems can read the same log for CDC.

Logical shard

One of a fixed number of shards, many more than nodes, that a separate map assigns to nodes. Keys map to shards by a hash that never changes. Adding a node moves whole shards and changes only the map.

Long polling

The server holds a request open until it has new data or a timeout, then the client asks again. Long polling gives near real-time updates over plain HTTP, without new infrastructure.

Lost update

A write that overwrites another write that it never saw. Two transactions read a value, change it, and write it back; one change disappears. An atomic update or compare-and-set prevents it.

LRU (Least Recently Used)

An eviction policy that drops the value read longest ago. It is the usual default for caches. A single pass over cold data can push out the hot values.

LSM-tree (Log-structured merge-tree)

A storage engine that collects writes in memory and writes them out as sorted files merged in the background. The log is appended in order, and sorted files are written and merged in order, so writes tend to be fast. Reads may check several files, and compaction can fall behind under heavy writes.

Lua script

A small program that Redis runs on the server as one command, with no other command in between. It can read, decide, and write in one round trip. While it runs, every other client waits, and an error does not undo the writes it already made.

Materialized view

A query result stored as a table and refreshed on demand. Reads are cheap, but the data is as old as the last refresh, and a refresh runs the whole query again.

Materializing the conflict

Turning a rule across many rows into one row that every transaction affected by the rule must write. The conflict becomes an ordinary conflict on one row, which locks or snapshot isolation already catch. A counter per buyer is an example.

MD5

A 128-bit hash function, broken for security but still used to spread keys. Its output is the same on every machine, so a database can place keys with it. Do not use it for passwords or signatures.

Memtable

A sorted structure in memory that collects new writes before they go to disk. When it is full, it is written out as a new SSTable in one sequential write. A WAL protects it from a crash.

Merge join

A join that walks two inputs sorted by the join key side by side. It is often useful when both inputs already come sorted.

Merge sort

A sorting method that sorts parts separately and then merges the sorted parts in one pass. Merging sorted inputs reads each of them once, in order, which suits files on disk.

Merkle tree

A tree of hashes in which each parent hash covers the hashes below it. Two replicas compare the roots and walk down only where hashes differ, so they find different ranges without sending all the data.

Monotonic clock

A clock that only moves forward, used to measure time passed on one machine. Use it for timeouts and durations. Its values cannot be compared across machines.

Monotonic reads

The guarantee that a user never sees older data after seeing newer data. Keep each user on one replica while it is up, and track the newest position the user has seen to stay safe after a switch.

Monotonic writes

The guarantee that a user's writes apply in the order the user made them. One leader with an intact log gives it to a user who waits for each write. Failover, parallel requests, or several leaders need tracking.

mTLS (Mutual TLS)

TLS in which both sides show a certificate. Each side proves who it is to the other, so only known services can connect. It is common for traffic between internal services.

MULTI and EXEC

Redis commands that queue a group of commands and run them in a row, with no other client in between. There is no rollback: a command that fails at run time fails alone. The client gets the results only after EXEC, so it cannot use one to decide what to queue next.

Multi-leader replication

Replication where several leaders accept writes and replicate them to each other. Each region writes locally and survives being cut off, but concurrent writes conflict and rules over all the data cannot be checked.

MurmurHash

A fast hash function that is not meant for security. It gives the same result on every machine and spreads similar inputs evenly, so databases such as Cassandra use it to place keys.

MVCC (Multi-version concurrency control)

Keeping several versions of a row so that each transaction reads the one it should see. Plain reads do not block writers, and writers do not block plain reads. Old versions stay until no transaction needs them, so long transactions make data grow.

Negative caching

Caching the fact that a value does not exist, or that a call failed. Repeated requests for missing data or a failing call stop reaching the source. Give such entries a short TTL, and never share an error that depends on the user.

Nested loop

A join that runs its inner side once for each row of its outer side. It is often fast when the outer side is small and the inner side is an index lookup.

Network partition

A network failure that splits nodes into groups that cannot reach each other. During a partition, a system with copies cannot both stay linearizable and complete every request. A node sees a partition only as a timeout.

No-show

A customer with a booking who neither arrives nor cancels. The unit stays unused, though another buyer would have paid for it. The share of no-shows and its spread decide how far a business may overbook.

Noisy neighbor

A tenant whose heavy load slows other tenants that share its resources. Per-tenant limits, a dedicated shard, or a silo keep one tenant from degrading the rest.

Normalization

Storing each fact once and referring to it by key everywhere else. An update changes one place, so copies cannot disagree. The price is joins on reads.

NTP (Network Time Protocol)

A protocol that sets a machine's clock from servers with better clocks. It keeps clocks close, often within milliseconds, but a correction can move a clock back, and it gives no guaranteed bound.

Object storage

A store of files under keys in one flat namespace, read and written whole over HTTP. It is cheap, grows without limit, and keeps files durable. Amazon S3 is the best-known one.

Offer with a deadline

A hold that waits for one chosen person's answer until a deadline. The acceptance and the expiry are conditional updates that both check the deadline, so a late acceptance loses. A timer that survives restarts acts on the deadline, and the business decides what an expired offer returns.

OLAP (Online analytical processing)

The workload of analytics: large scans and totals over many records. It often reads few columns of many records, which suits column storage. Analytics usually runs in a separate store loaded from the main one.

OLTP (Online transaction processing)

The workload of an app: many small reads and writes of single records by key. It needs fast lookups and steady latency. Row storage usually suits it.

Optimistic locking

Checking at write time that a row has not changed since it was read, usually by a version number. No lock is held between the read and the write. On a conflict the work is retried, so it suits rows that rarely conflict.

OSI model (Open Systems Interconnection model)

A model that divides network communication into seven layers. Each layer describes a different part of communication. The layer numbers help distinguish addressing (L3), transport (L4), and application messages (L7) when discussing protocols and load balancers.

Read more: Networking: Adding servers

Outbox

A table where the app writes an event in the same transaction as the change it describes. The change and its event commit together or not at all. A separate process delivers the events later and may retry.

Overbooking

Selling more units than exist, on purpose, because some buyers do not come. It fills units that no-shows would leave empty, at the cost of compensating the buyers who find no unit. It fits units with a near equivalent and a bounded cost per broken promise.

PACELC

The rule that adds to CAP: without a partition, a system trades latency against consistency. Every operation that must confirm with other copies waits for the network, even when nothing fails.

Page cache

Memory where the operating system keeps recently read and written parts of files. Reads of hot data skip the disk. Written data waits there before it reaches the disk, so a power loss can erase it until a flush.

Partial index

An index over only the rows that match a condition. It is smaller and cheaper to update. The planner uses it only when it can prove from the query that the rows match its condition.

Partition key

The part of a key that decides which partition holds a record, and so which machines store it. A query that names it stays within one partition. Each partition must stay bounded in size.

Patroni

A tool that runs PostgreSQL failover by keeping a leader key in a coordination service such as etcd. The server that holds the key is the primary; others promote themselves only after the key expires.

Paxos

A family of consensus algorithms; Multi-Paxos agrees on a log of values with a stable leader. For a design it gives the same as Raft: a log agreed by a majority. Spanner and Chubby use it.

Percentile

The value below which a given share of measurements falls. The 99th percentile of latency is the time that 99% of requests beat. It shows slow requests that an average hides.

Pessimistic locking

Locking rows when they are read, so that no other transaction can change them before the write. Conflicting transactions wait instead of failing. It suits rows that many transactions want at once.

pg_stat_statements

A PostgreSQL extension that counts calls, total time, and pages read for each kind of query. Sorting by total time shows which queries cost the database the most.

Phantom

A write by one transaction that changes which rows match another transaction's search. The rows that match now did not match when the search ran, so there was nothing to lock. Range locks, a shared row that both write, or serializable isolation prevent the damage.

Physical replication

Replication that sends the changed bytes of pages from the WAL. Followers become exact copies, but every replica needs the same storage format, usually the same major version, so a major upgrade usually needs downtime.

Pipelining

Sending many commands without waiting for each reply, then reading all replies together. It pays one network round trip for many commands and saves system calls on the server. It is not a transaction: other clients' commands can run in between.

Pivot

The step of a saga after which it can no longer be undone and must finish. Steps before it have compensations; steps after it are retried until they succeed.

Point-in-time recovery

Restoring a database to a chosen moment covered by a snapshot and an unbroken archived log. Restore the last snapshot before a mistake and replay the log up to just before it.

Polling

The client asks the server for new data again and again on a timer. Polling is simple and works everywhere. The cost is delay (up to one interval) and many empty requests.

Pool model

Storing all tenants in shared databases and tables, told apart by a tenant ID in every row. Cheap and simple to run and to onboard new tenants, but an outage or a heavy tenant affects everyone.

Port

A number that identifies a program on a machine, so one IP address can serve many programs. A connection goes to an IP address and a port, for example port 443 for HTTPS. L4 load balancers route traffic by IP address and port.

PostGIS

A PostgreSQL extension for places and shapes: types, distance functions, and spatial indexes. It answers queries such as "homes within 5 km" through a GiST index.

Postmaster

The main PostgreSQL process that accepts connections and starts a process for each one. When a backend crashes, it ends the other backends and recovers the database from its log, which interrupts every client.

Pre-signed URL

A time-limited link that allows one kind of operation on one object, such as an upload to one key. The client sends or gets the file straight from object storage, bypassing the app servers. The link works until it expires, so it can be used more than once.

Primary (PostgreSQL)

The PostgreSQL server that takes writes and streams its WAL to standbys. In general terms it is the leader. A cluster has one primary at a time; failover promotes a standby in its place.

Primary key

The column or columns that identify each record of a table. No two records share it. The database keeps an index on it to find records by it.

Private cache

An HTTP cache that serves one user, such as a browser. It may keep personal responses. The server cannot remove a response from it before its lifetime ends.

Probabilistic early refresh

Refreshing a cached value before it expires, with a chance that grows near the expiry. Reads rarely refresh at the same moment, so a stampede shrinks to a few loads without a lock. It does not help after a delete.

Pub/Sub

Messaging where a sender publishes to a channel and every subscriber of the channel receives the message. Some systems keep the messages for subscribers that are away. Redis Pub/Sub keeps nothing, so a subscriber that is away or too slow loses them.

Query plan

The steps a database chooses to run a query, such as which index to use. Databases show it on request (EXPLAIN in SQL). Check it to see whether a query really uses the index you added.

Query planner

The part of a database that chooses how to run a query by its estimated cost. Its estimates come from statistics about the data, so a wrong estimate can lead to a slow plan.

QUIC

A transport protocol on top of UDP that gives reliable streams with built-in encryption. QUIC does what TCP and TLS do together, but each stream recovers from loss on its own. HTTP/3 runs on QUIC.

Quorum

The number of replicas that must answer a read or a write. With N replicas, W write answers, and R read answers, W + R > N makes the read and write sets overlap, so a read usually reaches the latest confirmed write. It is not a strong guarantee.

Quota

A share of a limited stock that one server or region may sell without asking the others. Sales need no shared row, but units get stranded: one place turns buyers away while another still has stock. A quota moves only after its old owner records that it gave it up.

Raft

A consensus algorithm in which one elected leader replicates a log to the other nodes. A leader commits an entry of its current term once a majority has saved it, along with every entry before it. etcd, Consul, and CockroachDB use it.

RAM (Random-access memory)

The main memory of a server: fast, but lost on restart and much more expensive than disk. Data and indexes that fit in RAM are read without disk access.

Range partitioning

Giving each shard a contiguous range of key values. Range reads stay on one shard or a few neighbors, and ranges split as they grow. Keys written in order, such as timestamps, all land in the last range.

Range type

A column type that holds a period or interval, such as a range of dates, as one value. The database can then compare ranges directly, for example check whether two bookings overlap.

Rate limit

A cap on how many requests a client may send in a period of time. Rate limits protect a service from overload and abuse. Requests over the limit usually get HTTP 429.

RDB snapshot (Redis Database snapshot)

A Redis file with the whole dataset at one moment. BGSAVE writes it from a forked child process, SAVE in the main process, which blocks clients. It is compact and loads fast, a good backup; a crash loses everything written since the last one.

Read committed

The isolation level at which each statement sees only committed data. It prevents dirty reads and dirty writes, and it is the default in most databases. Data can still change between two statements of one transaction.

Read repair

Fixing an old replica during a read by writing the newest or missing versions back to it. It repairs keys that are read often and leaves rarely read keys old.

Read skew

Reads in one transaction that see the data at different moments, so their results disagree. Reading the same row twice and getting two values is its simplest form, a non-repeatable read. Snapshot isolation prevents it.

Read uncommitted

The lowest isolation level, which lets a transaction see uncommitted changes. It allows dirty reads and is rarely useful.

Read-through

A caching pattern where the cache itself loads a missing value from the source. The miss logic lives in one place. The cache must know the source, and the app needs a planned way to the data when the cache is down.

Read-your-writes

The guarantee that a user's reads include the user's own completed writes. Read a user's own data from the leader, or only from replicas that have applied the user's last write.

Rebalancing

Moving shards between nodes so that data and load spread evenly again. A move copies a snapshot, streams the changes, and switches the shard map after a short write pause. Moves add load, so plan them before peaks.

Recall

The share of the true nearest neighbors that an approximate search returns. Approximate indexes trade recall for speed and memory.

Redis

An in-memory server that stores data structures under keys and runs commands on them. A small command takes far less time than the network round trip, so it often sits next to a database for caches, sessions, counters, and queues. Its copies are asynchronous, so a crash or failover can lose recent writes.

Redis Cluster

Redis's built-in sharding: keys map to 16,384 hash slots spread over several primaries. Clients send each command straight to the owner of the key's slot. Commands on several keys work only within one slot.

Redis function

A named script that Redis stores and copies to replicas together with the data. Unlike scripts sent with EVAL, functions survive restarts and failovers, so clients do not have to load them again.

Redis Sentinel

Processes that watch a Redis primary and promote a replica when it fails. Run at least three on separate machines. A failover needs a majority of them and can still lose recent writes.

Redis stream

An append-only log of entries stored under one Redis key. Consumer groups share its entries among workers with acknowledgments and redelivery. It lives on one server and in its memory.

Relational model

A data model that keeps data in tables of rows linked by keys. Queries combine tables with joins, and the database enforces rules with constraints. It is the default for data with many relations and rules.

Remote cache

A cache on its own servers that all app servers use over the network. The app servers share one copy of each value and can delete it in one place. Each read costs a network round trip.

Rendezvous hashing

Sending each key to the node with the highest hash of the pair (key, node). Like consistent hashing, it moves few keys when nodes change, and needs no ring.

Repeatable read

The isolation level of the SQL standard that rules out non-repeatable reads. Databases with row versions usually provide it as snapshot isolation, others with shared locks. What it allows differs between products.

Replica

One copy of the data in a replicated system. In a leader-based design, a replica is either the leader or a follower.

Replication

Keeping a copy of the same data on several nodes. Copies let the data survive the loss of a node, spread reads, and sit close to users. The hard part is keeping them in step while the data changes.

Replication lag

The delay between a write on the leader and the same write on a follower. It is usually under a second but has no upper limit, and reads from a follower that is behind return old data.

Replication log

The stream of changes that a leader sends to its followers, in the order it applied them. It can carry statements, pages of the WAL, or changed rows. A position in it measures how far a follower has got.

Replication slot

A record on the primary that makes it keep the WAL a consumer still needs. A stopped consumer makes WAL pile up. A retention budget checked at checkpoints can invalidate the slot; monitor the WAL each slot holds and the free disk.

Request coalescing

Letting one request load a missing value while others asking for it wait for the result. It turns many identical loads into one. Done per server, it leaves one load per server.

REST (Representational State Transfer)

An API style built on resources (URLs) and standard HTTP methods. Each thing is a resource with a URL, such as /orders/42. Clients read and change it with GET, POST, PUT, and DELETE. REST is the default style for public APIs.

Retention

How long data is kept before it is deleted. Stores that keep data in time blocks drop a whole expired block at once, far cheaper than deleting rows one by one.

Revalidation

Asking the server whether a stored response is still current instead of downloading it again. The cache sends the ETag or Last-Modified value back. If nothing changed, the server answers 304 Not Modified with no body.

Rollback

The end of a transaction that discards all of its changes. The app rolls back when a check fails, and after a crash the database rolls back every transaction that did not commit.

Rollup

A precomputed summary of detailed data at a lower resolution, such as one point per hour. It keeps long history affordable and makes repeated numbers cheap to show.

Round robin

Sending each new request to the next server in turn. Round robin is simple and works well when requests cost about the same.

Round trip

The time for a message to reach the other side and for the answer to come back. Also called RTT (round-trip time). Every handshake costs at least one round trip, so distance between client and server adds up fast.

Row storage

Keeping all values of a record together in one place. It suits apps that read and write a few whole records at a time. A query that needs a few columns of many records still reads whole rows.

Row version

One state of a row, kept so that each transaction can read the state it should see. Versions are kept as separate copies of the row or rebuilt from an undo log. Readers pick the version they should see, and old versions are cleaned up later.

RPO (Recovery point objective)

The largest window of recent data a system may lose in a failure, set as a target. A failover to an asynchronous follower typically loses up to its lag. Synchronous replication can bring it to zero for the loss of one node.

RTO (Recovery time objective)

The longest time a system may take to recover from a failure, set as a target. A failover takes seconds to minutes. A restore of a large database from backups can take hours.

Saga

A chain of local transactions in which steps that may need undoing have compensating steps. No locks span services or shards, and other requests can see the state between steps. It finishes only if its retries and compensations do.

Salting

Adding a suffix to a hot key so that its writes spread over many keys and shards. Reading all the data of the original key then means reading every suffix and merging the results.

Scatter-gather

Sending a query to every shard and merging the results. Every shard does the work, and the slowest shard sets the latency, so keep such queries rare.

Schema

The structure that records follow: their fields and the types of the fields. A relational table enforces its schema on every write. Without that check, the code that reads the data still relies on one.

Schema-on-write / schema-on-read

Two places to check the structure of records: when they are written, or when they are read. Schema-on-write rejects bad records but needs migrations to change. With schema-on-read the store does not check records on write, so readers must handle every shape ever written.

Search engine

A separate store built for full-text search, such as Elasticsearch or OpenSearch. It adds language analysis, tuned relevance, and facets. In most designs it holds a copy of data owned elsewhere, which lags behind.

Secondary index

An additional index that finds records by columns other than the primary key. Values need not be unique, so each entry also identifies its record: by its place in the table or by its primary key. Every write that changes the indexed columns must update it.

Semantic lock

A mark that a record is in the middle of a saga, which other operations check. Pending money cannot be spent, and an operation on a marked record is refused or waits until the saga ends.

Semi-synchronous replication

Replication with one synchronous follower and the rest asynchronous. While the synchronous follower answers, every confirmed write is on two nodes. Some products fall back to asynchronous replication when it does not answer in time.

Sequence (database)

A database object that generates a series of numbers, commonly for IDs. A rollback does not return a number, so gaps are normal; uniqueness comes from a key, not from the sequence.

Sequential consistency

The guarantee that all operations fit one order that keeps each client's own order. The order need not follow real time between clients, so a read may miss a write another client has finished. Like linearizability, it makes some nodes refuse requests during a partition.

Serial execution

Running transactions one after another on one thread, so they never overlap. It gives serializable isolation without locks and works best with short transactions on data in memory. One thread caps throughput.

Serializable

The isolation level at which concurrent transactions end as if they had run one after another. It rules out every anomaly, at the cost of waits or retries. It covers only transactions that run at this level.

Serialization error

An error by which the database aborts a transaction that conflicts with a concurrent one. The app must run the whole transaction again from the start.

Service discovery

A way for services to find the current addresses of other services. Instances register themselves, and clients ask the registry for healthy instances. A load balancer or the client itself uses it to pick a live instance.

Shard

One part of a dataset that is split across nodes; sharding is the split itself. Each row lives in exactly one shard, and each shard has its own leader and followers, so data and writes can grow past one machine.

Shard directory

A table that maps each key, such as a tenant, to the shard that holds it. It lets you place and move one tenant at a time. Every request needs a lookup, so the directory must stay available.

Shard key

The column whose value decides which shard holds a row. A query that names it goes to one shard; a query without it asks every shard. Changing it later means moving every row.

Sharded Pub/Sub

Pub/Sub in Redis Cluster where each channel belongs to one shard, like a key. Messages stay inside one shard instead of going to every node, so more shards mean more capacity.

Shared buffers

The page cache that all PostgreSQL processes share in memory. Pages are read and changed here and written to the data files later. A common start is a quarter of RAM; the OS page cache holds more.

Shared cache

An HTTP cache that serves many users, such as a CDN or a reverse proxy. One stored response answers many readers. It must never store a personal response, so mark those private.

Shared lock

A lock that many readers can hold at once, but that makes a writer wait. A reader that keeps it until commit sees the same rows on every read. Readers and writers then block each other.

Siblings

Concurrent versions of one record that a database keeps instead of choosing one. The app merges them on the next read or asks the user.

Signaling

Exchanging connection details between two peers before they connect directly. WebRTC does not define how signaling works. Apps usually send it through a server they already have, for example over WebSocket.

Silo model

Giving each tenant a database of its own. It keeps one tenant's load and failures away from the others and allows per-tenant backup, restore, and data residency, at the cost of many databases to run.

Single point of failure

A part whose failure stops the whole system. Remove it by running more than one copy and switching to a healthy one automatically.

Size-tiered compaction

A compaction strategy that merges files of similar size. It rewrites data fewer times than leveled compaction, so writes are cheaper. Reads check more files, and merges need more spare disk space.

Skew

An uneven split of data or load across shards. Even when keys spread evenly, some key values carry far more data or requests, such as one large tenant. The busiest shard runs out of capacity first, while others sit idle.

SLA (Service-level agreement)

A promise from a provider about a service level, such as monthly availability. Breaking it usually earns the customer a credit, not the lost time back.

Sloppy quorum

Counting writes on substitute nodes toward a quorum when the usual replicas do not answer. Writes keep succeeding during failures, but reads from the usual replicas may miss them until the handoff.

Snapshot

The state of data at one moment. An in-memory store saves one to disk for recovery and replays the log written after it. A transaction can read from one, so data does not change under it.

Snapshot isolation

An isolation level at which a transaction reads the data as it was when the transaction started. Later commits are invisible to it, so all its reads agree. It prevents read skew and lost updates, but not write skew.

Sparse index

An index that keeps one key per block of sorted records instead of one key per record. A read finds the right block and scans it. The index is much smaller, so it fits in memory for far more data.

Split brain

Two nodes acting as leader at the same time. Both accept writes, and the writes conflict. It happens when an old leader was only slow or cut off.

SQL (Structured Query Language)

The standard language for querying and changing data in relational databases. A query says what data it needs, and the database chooses how to get it, such as which indexes to use.

SSE (Server-Sent Events)

A long HTTP response through which the server streams text events to the client. Browsers reconnect by themselves and send the ID of the last event, if the server sets IDs. SSE sends data only from server to client.

SSI (Serializable snapshot isolation)

A way to get serializable isolation by reading from snapshots and aborting transactions whose reads and writes conflict. Reads never wait, but some transactions fail, including false alarms, and must be retried. Two writers of one row still wait as usual.

SSTable (Sorted String Table)

A data file whose records are sorted by key and never change after it is written. The order allows a sparse index, range reads, and cheap merges. LSM-trees store their data in SSTables.

Stale read

A read that returns an older version of data than the latest write. It happens on a replica that has not applied the write yet. Decide for each read whether an old answer is acceptable.

Standby

A PostgreSQL server that replays the WAL of the primary and keeps a copy of its data. It serves reads and can take over when the primary fails. In general terms it is a follower.

State machine replication

Keeping replicas equal by applying the same deterministic commands in the same order from the same state. Consensus agrees on the order of the commands in a log. Values that could differ between replicas, such as timestamps, are chosen once and stored in the command.

Stateless

Keeping no user data on the server between requests. Each request carries what the server needs, and user data lives in a shared store. Any server can then handle any request, which makes scaling and failures simpler.

Statement-based replication

Replication that sends each write statement for followers to run again. The log is small, but statements such as UUID() or an update with LIMIT can give a different result on each replica.

Sticky sessions

Sending all requests from one client to the same server. It keeps server-local state usable, but makes failover and rebalancing harder.

Storage engine

The part of a database that stores records on disk or in memory and finds them again. It decides which reads and writes are cheap. Most engines are built on a B-tree or an LSM-tree, and the choice follows the workload.

Streaming replication

PostgreSQL replication that sends WAL records to standbys over a connection as they are written. Each standby is an exact copy of the whole instance on the same major version.

Strict serializability

Serializable transactions in an order that matches real time. A transaction that commits before another starts comes first. Spanner provides it with commit wait.

Sweeper

A background job that finds expired holds and returns their units. It reads an index on the expiry in small batches and uses a conditional update, so it is safe to run twice or next to a confirmation. Its interval, plus any backlog, is how long a dead hold keeps units out of sale.

Synchronous replication

Replication where the leader confirms a write only after a follower has saved it. A confirmed write survives the loss of the leader if failover promotes a follower that has it. Every write waits for the follower, and writes stop when it fails.

System of record

The store that owns a fact: it is written first and wins when copies disagree. Every other copy of the fact is derived from it.

Table partitioning

Splitting one table into several tables on the same server, by ranges, lists, or hashes of a column. Old data leaves by dropping a partition, and queries skip partitions that cannot match. It adds no capacity.

TCP (Transmission Control Protocol)

A transport protocol that delivers a reliable, ordered stream of bytes over a connection. TCP opens a connection with a handshake, numbers every byte, and resends what gets lost. This makes it reliable, but a lost packet delays all data after it. HTTP/1.1, HTTP/2, and most databases run on TCP.

Term

In Raft, the number of an election period, with at most one leader per term. Every message carries the term, and nodes reject older terms, which stops an old leader.

TID (Tuple identifier)

The address of a row in a PostgreSQL table: a page number and a slot on that page. B-tree indexes map their keys to TIDs. A TID changes when the row is updated, so it is not an ID for the app.

Time-of-day clock

A clock that returns the date and time, corrected by a sync service such as NTP. It can jump forward or back, and clocks on different machines are not guaranteed to agree, so its timestamps cannot order close events on different nodes.

Time-series store

A store built for measurements over time, typically appended in time order and queried over recent windows. Many such stores keep data in time blocks, so old data is dropped cheaply, and some compute rollups for long history.

Timestamp oracle

One service that hands out increasing timestamps to transactions. It gives an exact order, but every transaction waits for its answers, so it should sit close to them and be replicated. Percolator and TiDB use one.

TinyLFU

A cache admission policy that lets a new value in only if it is read more often than the value it would replace. It keeps an approximate count of recent reads per key. One-off reads, such as a scan, mostly stay out.

TLS (Transport Layer Security)

The protocol that encrypts a connection and proves the server is who it claims to be. During the TLS handshake, the client checks the server certificate and both sides agree on keys. After that, all data is encrypted. HTTPS is HTTP over TLS.

TOAST (The oversized-attribute storage technique)

The way PostgreSQL compresses long values of a wide row and may move them to a separate table. It starts when a row is wider than about 2 KB. A query that does not ask for a moved value never fetches it.

Tombstone

A record that marks a key as deleted. Files that are only appended to cannot erase a record, so a delete writes a tombstone. It must stay until no older file can bring the deleted value back, and until compaction removes the key, the deleted data is still on disk.

Torn page

A page that a crash left half old and half new, because the disk wrote only part of it. PostgreSQL writes a full copy of each page to the WAL on its first change after a checkpoint, so recovery can repair a torn page.

Transaction

A group of reads and writes that the database applies as one unit. Either all of its changes happen or none do, and concurrent transactions do not see each other's half-done work.

Transaction ID

A number a database gives each transaction that writes, in increasing order. In PostgreSQL it has 32 bits and wraps around, so vacuuming must freeze old rows before it runs out.

Transaction mode

A pooler mode that lends a client a server connection only for one transaction. A few dozen server connections can serve thousands of clients, but session state such as SET or LISTEN does not survive between transactions.

TrueTime

Spanner's clock, which returns an interval that surely contains the real time. GPS receivers and atomic clocks keep the interval to a few milliseconds, and commit wait uses it to order transactions by real time.

Try, confirm, cancel

A saga form whose first step only holds a resource, and later steps confirm or release the hold. The middle state is a hold, not a move, so other requests see less that may be undone.

tsvector

A PostgreSQL value that holds the searchable words of a text, called lexemes, optionally with positions and weights. A GIN index over it finds the rows that contain the words of a query.

TTL (Time To Live)

How long a piece of data stays valid before it must be refreshed or dropped. Caches and DNS answers use a TTL to limit how long stored data can be reused. A short TTL means fresher data but more refreshes. A long TTL means fewer refreshes, but changes spread more slowly.

TURN (Traversal Using Relays around NAT)

A relay server that forwards traffic between peers when they cannot connect directly. TURN relays media when a direct connection is not possible. All media then goes through the relay, so it needs enough bandwidth.

Two-phase commit

A protocol in which participants first prepare a change and vote, then all commit if every vote is yes, or all abort. A prepared participant must follow the final decision, so a failed coordinator leaves it waiting with changes locked. It gives atomicity, not isolation.

UDP (User Datagram Protocol)

A transport protocol that sends separate messages with no delivery or order guarantees. UDP has no connection and no resends, so it adds very little delay. The application must handle loss and order itself if it cares. Live audio, video, games, and QUIC use UDP.

Undo log

A separate area that keeps the old values of rows changed in place. A rollback copies the old values back, and readers that need an older version rebuild it from there.

Unlogged table

A PostgreSQL table whose writes skip the WAL. Writes are much cheaper, but the table is empty after a crash and is not copied to standbys, which suits caches.

VACUUM

The PostgreSQL process that removes row versions no transaction can see and makes their space reusable. It runs next to normal work and rarely shrinks files. It also freezes old rows against transaction ID wraparound.

Valkey

An open-source fork of Redis 7.2.4, run by the Linux Foundation under the BSD license. It keeps the protocol and core features of Redis, so most clients work with both. Newer features of the two differ.

Vector clock

A set of counters, one per node, attached to events to detect which ones are concurrent. It shows whether one event happens before another or neither does, at the cost of a counter per node in every message.

Version vector

A counter per replica for each key that shows which writes a version has seen. Comparing two vectors tells whether one write replaced the other or both were concurrent. A timestamp cannot tell.

Vertical scaling

Handling more load by moving to a bigger machine. The code does not change, but the largest machine is a hard ceiling, and maintenance on one huge database gets slow.

Virtual node

One of many positions that a node takes on a consistent hashing ring. Many positions per node even out the load, spread a failed node over the rest, and let a bigger machine take more keys.

Waiting room

A queue in front of a site that lets visitors in at a pace the system can serve. It limits visitors inside and new visitors per minute, and the server checks a token that each admitted visitor gets. Admission does not promise a unit of stock.

WAL (Write-ahead log)

A log on disk where changes are written before the data files they change. After a crash, the database replays it to rebuild the memtable of an LSM-tree or to repair half-written pages of a B-tree. A write is confirmed once its log record is flushed.

WebRTC (Web Real-Time Communication)

A technology for direct peer-to-peer audio, video, and data in browsers and mobile apps. Peers connect to each other over UDP when they can. A signaling server, STUN, and TURN help them find each other through NAT.

WebSocket

A long-lived connection where client and server can both send messages at any time. It starts as an HTTP request and then upgrades to a two-way channel on the same TCP connection. Used for chat, collaboration, and games.

Weighted round robin

Round robin that sends more requests to servers with a higher weight. Weights follow server capacity, so a server twice as big gets twice the traffic.

Wide-column model

A data model that groups rows into partitions by key and sorts the rows inside each partition. A query reads a range of rows from one partition. Stores of this kind spread partitions across many machines and suit heavy writes.

Working set

The data a system reads within a period, often a small part of all its data. Size a cache for the working set, not for the whole data. When it does not fit, the hit ratio falls.

Write skew

Two transactions that read the same data and write different rows, together breaking a rule that each one kept. No two writes touch the same row, so row locks and snapshot isolation miss it. A shared row that both write, a unique constraint, or serializable isolation stops it.

Write-around

A caching pattern where writes go only to the source and the cache fills on the next miss. It keeps unread values out of the cache. Pair it with a delete of the key, or readers see the old value until its TTL ends.

Write-behind

A caching pattern where writes go to the cache and reach the source later, in batches. It turns many small writes into a few large ones. Writes not yet flushed are lost if the cache fails, so the cache becomes a store.

Write-through

A caching pattern where each write updates the source and the cache before it returns. A read right after a write is likely to hit. Every write pays a second step, the cache fills with values that may never be read, and failed or reordered updates still need a TTL.

Writes follow reads

The guarantee that a write applies after the writes its author had read. A reply is never applied before the post it answers. One leader with an intact log gives it to a user who waits for each write.

XA (eXtended Architecture)

A standard for running two-phase commit across different products, such as a database and a message broker. Each product must support prepare, and every product adds its own failure and recovery cases.

ZAB (ZooKeeper Atomic Broadcast)

The consensus protocol of ZooKeeper, which orders all writes through one leader. It gives the same guarantees as Raft for writes; ZooKeeper reads come from any server and may be behind.