System Design Glossary
The canonical language for this workspace. Terms are promoted here only once Poonnachit has used one correctly — this file is a record of compressed understanding, not a dictionary to read.
Where the wider field uses a term loosely, this workspace defers to Jepsen's consistency map.
Replication
Replication: A replica following the primary's durable change log and replaying every entry, in order, into its own full copy of the data. Makes copies; does not split data. Avoid: syncing, mirroring, "copying the database"
WAL (write-ahead log): The ordered, durable log of every change, written before a commit is acknowledged. Exists for crash recovery; replication is the realisation that another machine can replay it too. PostgreSQL's name for it, and this workspace's. Avoid: binlog (MySQL's name — use it only when discussing MySQL), transaction log
Streaming replication: Replication in which the standby holds an open connection and receives WAL records as they are generated, rather than waiting for a completed log file. Avoid: live replication, real-time replication
LSN (log sequence number): A byte position in the WAL. The primary has a head position; a standby has a received position and a replayed position, and only the replayed one is visible to queries there. Avoid: offset, checkpoint, version number
Replication lag: The distance between the primary's head LSN and a standby's replayed LSN. A long-tailed distribution, worst under write bursts — not a constant. Avoid: delay, sync time
Consistency
Read-your-writes: The guarantee that after a user writes, that same user's later reads reflect it. Other users may still see the old value. A per-user promise, which is why it is cheap. Avoid: consistency (far too broad), read-after-write (acceptable, but pick one)
Monotonic reads: The guarantee that a user never sees time run backwards across successive reads. Avoid: ordering, stability
Idempotent: Safe to apply more than once with the same result. The property that lets a distributed system retry, duplicate and reorder an operation without breaking it — and the reason cache invalidation is a delete, not an update. Avoid: repeatable, safe
Caching
Look-aside cache: A cache the application asks first and fills itself on a miss. Never authoritative, never in the write path — which is what makes evicting from it always safe. Avoid: read-through cache (that is a different pattern — the cache does the fetching)
Remote marker (rk): A per-key flag meaning "this region's copy of k may still be behind." Its presence is the entire message; the value is irrelevant. Present ⇒ send the read to the master region. Avoid: lock, dirty bit, invalidation flag
Regional pool: Memcached servers shared by every frontend cluster in a region, holding one copy for the whole region instead of one copy per cluster. Where a remote marker must live, so that every cluster can see it. Avoid: shared cache, global cache
Topology
Frontend cluster: A self-contained unit of web servers plus its own cache servers, holding nothing that cannot be rebuilt. A region runs several, routed to randomly, and any one can be taken offline. Paired against the storage cluster — "frontend" here is a tier word, not a browser word. Avoid: app tier, web tier, edge
Storage cluster: The databases in a region — the only authoritative copy, and the thing every cache miss falls back to. Avoid: backend, persistence layer
Master / read-only replica: In a single-master topology, the one region whose databases accept writes, versus every other region's read-only copies. Chosen to avoid write conflicts entirely, at the cost of a long write path for distant users. Avoid: primary/secondary for the region-level relationship — reserve primary/standby for the database pair