System Design Terminology

A user-visible behavior or operation the system must support, such as creating a link or resolving a short code.

Why it matters: It defines what the architecture must do before technologies or scale mechanisms are chosen.

A measurable quality target or constraint, such as latency, availability, durability, freshness, security, or cost.

Why it matters: It supplies the pressure that justifies replication, caching, partitioning, or another architectural mechanism.

The durable record whose code-to-destination value and lifecycle state decide the official answer.

Why it matters: Caches and replicas may accelerate reads, but they must not silently invent a different owner or destination.

The single authoritative constraint or operation that selects one owner for a value such as a domain-and-code pair.

Why it matters: Randomness makes collisions less likely; only the boundary prevents two successful owners.

One indivisible mutation that either reserves a key or loses without overwriting the existing owner.

Why it matters: It closes the race left by checking availability before writing.

The ability to retry the same logical command without applying its effect more than once.

Why it matters: A timeout does not tell the client whether the first write committed, so safe replay needs stable request identity and a stored outcome.

An event-intent record committed in the same transaction as the business mutation and relayed afterward.

Why it matters: It prevents a committed database change from silently losing the intent to invalidate a cache or publish an event.

Maintaining copies of data on multiple nodes or locations under a stated write and lag policy.

Why it matters: It can improve survival and read capacity, but a replica is not automatically current and is not a substitute for backups.

A rule - often an epoch, lease, or token - that prevents an old writer from committing after ownership moves elsewhere.

Why it matters: Routing traffic away from a writer does not prove that the isolated process stopped writing.

The application checks a cache first, reads the authority on a miss, and best-effort fills the cache afterward.

Why it matters: It keeps the database authoritative while reducing repeated read work, but requires explicit miss, stale-fill, and outage behavior.

Mechanisms that let independent processes agree on ownership, ordering, or a shared transition despite concurrency and failure.

Why it matters: Coordination can protect correctness, but it adds latency, availability dependencies, and recovery rules.

A threshold below which a stated percentage of measured requests complete; p99 covers 99% of the measured population.

Why it matters: Averages can hide slow-tail behavior that users and dependent systems still experience.

One key that receives a disproportionate share of traffic and overloads the node, partition, or lock that owns it.

Why it matters: Adding more partitions spreads different keys but does not divide traffic for one viral key by itself.

A bounded decision to accept, queue, degrade, or reject work before an overloaded dependency is called.

Why it matters: It prevents fallback traffic from turning one dependency failure into a wider outage.

Dividing a dataset and its traffic across ownership ranges so each request can be routed to the correct subset.

Why it matters: It raises capacity but introduces routing, rebalancing, cross-partition operations, and migration correctness work.

Recovery Point Objective bounds tolerated data loss; Recovery Time Objective targets how quickly service is restored.

Why it matters: They turn vague disaster-recovery claims into testable data-survival and restoration expectations.