Appendix L — Glossary and Anti-Glossary

The launch review stops on three words: “The serverless pipeline is infinitely scalable and exactly once.” Everyone recognizes the intent. Nobody can derive a capacity plan, a correctness test, or a recovery action from it. Does “serverless” transfer operation of the application, or only host provisioning? Does “scalable” refer to admitted events, stored bytes, tenants, or regions? Which effect occurs once, under whose authority, across what retry window?

Vague language is not merely a prose defect. It moves an unstated assumption into the architecture. This appendix supplies a controlled vocabulary for performance decisions and an anti-glossary for phrases that must be repaired before they can support one. Use it while writing objectives, diagrams, benchmark claims, incident hypotheses, and review decisions.

The companion registry at examples/performance-engineering-system-design-handbook/appendices/terminology-registry/terms.json preserves the families and required qualifier fields as data. Its verifier checks coverage, not the truth of a particular system claim.

The grammar behind a defensible term

A useful performance statement usually names six things: boundary, unit, population, state, interval, and evidence status. “Latency fell” becomes reviewable only after it says which operation, which start and end events, which requests, under which workload and failure state, during which interval, and whether the result was observed or modeled.

Keep four categories separate:

• An objective says what must be true, for whom, and under which conditions.
• A mechanism says how work, state, and resources produce behavior.
• A measurement says how an observation was made and summarized.
• A guarantee says which outcomes remain possible across named failures.

“p99” is a statistic, not an objective until a threshold and compliance rule are attached. “Backpressure” is a mechanism, not proof that overload is safe. “Exactly once” is a guarantee claim, not a synonym for deduplication. A review should reject category changes disguised as shorthand.

Evidence labels are part of the vocabulary: observed comes from a scoped measurement; estimated uses bounded inputs; modeled follows an explicit abstraction; simulated comes from an executable model; inferred is the best explanation of evidence with alternatives still possible; proposed describes an unvalidated design. Never let a modeled number acquire the grammar of an observation as it moves into a slide.

Work and demand

Unit of work. The conserved or counted outcome used as a denominator: valid checkout, acknowledged event, rendered frame, answered query, or stored useful byte. Attempts and retries are usually work, but not necessarily useful units.

Offered load. Work presented to the system boundary before admission, expressed as a rate, concurrency, bytes, or another named demand dimension. Include retries when they cross the boundary.

Admitted load. The offered work accepted for processing after shedding, rate limiting, or capacity rejection. Acceptance must say whether durable enqueue, memory admission, or merely receipt completed.

Goodput. Correct, timely, non-duplicate useful outcomes per unit time. State the validity and deadline rules. Throughput can rise while goodput falls if retries, invalid results, or late work dominate.

Workload mix. The distribution of operation classes, sizes, tenants, keys, states, and dependency paths. A rate without its mix rarely transfers between environments.

Skew. Uneven demand or state concentration across keys, tenants, partitions, resources, or time. Report the distribution or concentration measure; “skewed” alone does not size the hot path.

Fan-out. The number and distribution of downstream operations initiated per unit of work, together with the completion rule: all, quorum, first valid, or optional. Fan-out attempts are not automatically independent.

Amplification. Resource work generated per useful unit beyond its direct payload: retries, replication, compaction, indexing, encoding, metadata, or repair. Name the stage and ratio.

Time and distributions

Latency. Elapsed time between two named events for one unit, measured by a named clock. It may include service, scheduling, queueing, coordination, transport, and retry time. It is not synonymous with CPU time.

Response time. End-to-end elapsed time visible at a specified requester boundary. Say whether failures, timeouts, cancellations, and asynchronous completion are included.

Service time. Time a resource actively serves a unit, under a declared accounting method. CPU service, device service, and remote service are different quantities and may overlap.

Queue time. Elapsed time between entering and leaving a named waiting stage. Include the queue owner, priority class, cancellation semantics, and clock.

Deadline. The latest acceptable completion event relative to a named origin. A deadline belongs to an outcome; it is not the same as a timeout.

Timeout. A mechanism that stops waiting or triggers another action after a duration. Say what is cancelled, what may continue, and what duplicate or recovery work follows.

Percentile. For a defined population or sample, a value at or below which the stated fraction lies under a declared quantile convention. Preserve loss handling, sample count, interval, aggregation, and approximation. Percentiles from separate hosts or windows cannot be averaged into the combined percentile.

Tail latency. A high region of a scoped latency distribution, not a universal percentile. Name the quantile or threshold, population, interval, and consequence.

Jitter. Variation in a named timing quantity under a declared method. It can mean delay variation, scheduling variation, or inter-arrival variation; use the specific term whenever possible.

Capacity, queues, and control

Service demand. Resource service consumed per useful unit, such as CPU-seconds/checkout or device-seconds/query. A measured total divided by goodput is valid only when attribution and conservation assumptions hold.

Capacity. Maximum sustainable useful work under named objectives, workload, topology, state, and duration. A brief throughput peak is not sustainable capacity.

Safe capacity. Capacity after explicit headroom and failure/recovery reservations, while correctness and objectives still hold. State the binding resource and scenario.

Utilization. Busy service time divided by available service time for a specified resource and interval. Host-average utilization can conceal a saturated core, shard, queue, quota, or dependency.

Saturation. A state in which a limiting resource or control cannot accept additional demand without growing wait, shedding work, violating an objective, or changing behavior. It is an observed mechanism, not merely “high utilization.”

Bottleneck. The constraint whose marginal capacity currently limits the named outcome. It can move with workload, skew, failure, or optimization; the busiest-looking component need not be causal.

Headroom. Reserved capacity between modeled or observed demand and a declared safe limit. State whether it covers uncertainty, bursts, failure, recovery, deployment, or growth; do not count one reserve twice.

Backpressure. Feedback that reduces or bounds upstream production when downstream capacity is unavailable. Name the signal, propagation path, buffer, reaction time, and behavior of senders that cannot slow.

Admission control. A decision at a named boundary to accept, defer, degrade, or reject work before a more expensive or correctness-sensitive commitment. Its quality is judged by protected goodput and fairness, not rejection count alone.

State, failure, and delivery

Availability. The fraction or probability that a defined operation can produce its valid outcome within its objective for a named population and interval. Reachability and a success status are not sufficient definitions.

Durability. The conditions under which an acknowledged effect survives specified failures and retention periods. Identify the acknowledgement point, authority, media, replicas, and correlated-loss assumptions.

Consistency. The allowed relationships among operation histories and observed state. Name the model, operation scope, authority, and failure assumptions; “strong” is not a model.

Idempotency. Reapplying an operation with the same identity has no additional externally relevant effect within a declared scope and retention window. It does not guarantee delivery, uniqueness of attempts, or atomicity across other effects.

At-most-once. Within a specified boundary, an effect occurs zero or one times. Loss remains possible.

At-least-once. Within a specified boundary and retry policy, an effect eventually occurs one or more times when stated liveness assumptions hold. Consumers must handle repeats.

Effectively once. The named business effect is made unique by identity, authority, atomic state, and replay behavior even though transport or computation may repeat. Define the effect; do not abbreviate it back to “exactly once.”

Failure domain. Components expected to fail together for a stated cause class. Placement labels such as host, zone, or region do not prove independence.

Blast radius. The affected population, operations, state, and duration when a named fault occurs. Count tenants or outcomes, not merely components.

Recovery time objective. The target duration from a named disruption event until a defined service or state condition is restored. Include detection and validation if they lie inside the promise.

Recovery point objective. The maximum acceptable gap between the restored state and the named pre-disruption reference event. It is a loss objective, not a replica-lag reading by itself.

Critical path. The dependency sequence or set that determines a named successful outcome in a scenario. Mandatory does not mean slow; background repair can become critical to a recovery objective.

Evidence and decisions

Population. Every unit to which a claim intends to apply, including inclusion, exclusion, success, and loss rules.

Sample. The observed subset and selection process. A large biased sample does not become representative through size.

Exemplar. One selected unit linked across metrics, traces, logs, profiles, or packets. It explains a path, not the population distribution by itself.

Baseline. The reference condition in a comparison, including workload, state, environment, versions, and capture semantics.

Treatment. The intentional change evaluated against the baseline. Incidental drift is a confounder, not part of the treatment.

Uncertainty. The bounded lack of knowledge from sampling, variation, measurement error, model assumptions, or future demand. State its source and how it affects the decision.

Transfer limit. A condition beyond which evidence should not be assumed to apply: different hardware, topology, mix, scale, failure mode, runtime, or duration.

The anti-glossary: phrases that owe the review more information

The following phrases are not forbidden. They are incomplete claims. Repair them with the listed qualifiers or replace them with a narrower statement.

Two further phrases deserve the same treatment. Highly available must name the operation, objective, failure classes, interval, maintenance policy, and evidence. Eventually consistent must name which state converges, under what liveness and conflict assumptions, how staleness is bounded or observed, and what reads may return before convergence.

Mercury repairs the launch sentence

The team decomposes “serverless, infinitely scalable, exactly once” into three claims:

1. The provider manages compute-instance provisioning and host maintenance. Mercury still owns admission limits, payment identity, data access, monitoring, regional recovery, and cost.
2. Modeled valid-event capacity grows from 4,000/s at 20 workers to 24,000/s at 120 workers under the current mix. A 30,000 write/s ledger-partition limit and a 1.6 GiB/s regional egress budget then bind. Failure capacity reserves 25%.
3. One ledger debit per payment ID is authoritative because debit, identity record, and input position commit atomically in that ledger. Notification delivery is at least once; a replay outside the 30-day identity window enters reconciliation.

The repaired claims are longer because the architecture is larger than the slogan. They also produce tests: scale through the stated range; inject worker and ledger failures; replay inside and outside the retention window; verify duplicate debit invariants; measure useful-event cost and recovery capacity. Language has become an executable review boundary.

Claim-repair drills

Repair a percentile. Rewrite “API p99 is 80 ms” with operation, endpoints, population, losses, interval, aggregation, sample count, workload, state, topology, evidence label, and objective. Then state one decision the resulting statistic still cannot support.

Repair a progress claim. A team calls a cache “lock free” because no mutex appears in its public code. Identify the operation, transitive allocator/reclamation path, progress property, platform, contention test, and fairness evidence needed. Explain why absence of a mutex name proves none of them.

Repair delivery language. A queue redelivers after consumer crash, while the handler charges a non-transactional external API and then records completion. Specify the unique business effect, identity authority, ambiguous outcome, retry policy, retention window, and reconciliation path. Decide whether effectively-once behavior can be built without claiming exactly-once transport.

Pocket language review

• Can the claim identify its boundary, unit, population, state, interval, and evidence status?
• Is it an objective, mechanism, measurement, or guarantee—and does the sentence keep that category?
• Do rate and resource numbers use a useful-work denominator?
• Do latency and percentile claims define events, loss, aggregation, and sample scope?
• Do capacity claims name objectives, range, binding resource, failure reserve, and economics?
• Do delivery claims name the unique effect, authority, identity, atomic boundary, and replay window?
• Do implementation labels name versions, platforms, fallbacks, and transfer limits?
• Would another reviewer derive the same test and failure behavior from the words?

The decision rule is: do not let a performance term authorize architecture, capacity, correctness, or rollout until its boundary and qualifiers make the claim falsifiable; when shorthand hides more than it communicates, replace it with the narrower mechanism and evidence statement.

Primary references and transfer notes

• RFC 7679 defines one-way delay samples and percentiles, including explicit treatment of undefined values. Application latency needs its own start/end events, population, and loss policy.
• RFC 9439 gives a precise percentile notation over an observation distribution. Telemetry implementations still differ in histogram boundaries, summaries, aggregation, and approximation.
• The C++ draft progress guarantees and lock-free atomic properties distinguish system-wide progress from per-thread completion and expose implementation-dependent lock-free properties. Other languages and algorithms require their own contracts.
• Linux MSG_ZEROCOPY documentation describes copy avoidance, buffer-lifetime notifications, overhead, and deferred-copy fallback; its name is not proof that every copy vanished.
• Apache Kafka’s design documentation scopes delivery and processing semantics around producer, broker, consumer, offsets, and transactions. External effects require an explicit authority and atomicity story.
• AWS’s serverless explanation explicitly retains servers while transferring routine infrastructure management to a provider. Exact responsibility, scaling, quota, cost, and recovery contracts remain service-specific.

Appendix M turns these definitions into calculations, critiques, incidents, benchmark audits, and staff-level design drills. Require participants to repair the language before debating the solution.