5 exercises on adjective–noun collocations used when discussing system performance, uptime, and reliability: the fixed terms that every SRE, backend engineer, and architect uses daily.
Key performance collocations in this set
high availability (HA) — not "full" or "maximum" availability
low latency — the pair to "high throughput"; never "zero latency"
eventual consistency — the CAP-theorem trade-off; not "temporary" consistency
idempotent — safe to repeat; distinct from atomic or deterministic
stateless — holds no session between requests; enables horizontal scale
0 / 5 completed
1 / 5
An SRE writes in a runbook:
"Our target is ___ availability — the system must remain operational 99.99% of the time, including during planned maintenance windows."
Which adjective pairs with "availability" to describe a system designed never to go down?
High availability (HA) is the canonical technical collocation. It refers to a system or component that is continuously operational for a desirably long period, typically expressed as a percentage of uptime (e.g., 99.9% = "three nines", 99.99% = "four nines"). The term is so established it has an acronym: HA. You will see it in cloud provider documentation (AWS HA, Azure HA), Kubernetes configurations, database clustering, and SLA definitions.
Why the others fail:
full availability — not a technical term; sounds informal
maximum availability — used colloquially but not the fixed technical phrase
total availability — not used professionally in this sense
Common collocations:
high availability cluster
high availability architecture
design for high availability
highly available system (adjective form)
2 / 5
A backend engineer explains a performance requirement:
"For real-time trading, we need ___ latency — any delay over 5ms in order processing is unacceptable."
Which adjective is the standard technical pairing with "latency" to describe minimal delay?
Low latency is the established technical collocation. Latency is the time it takes for a request to travel from sender to receiver and back. "Low latency" means this delay is as small as possible — it is the standard term in networking, real-time systems, high-frequency trading (HFT), gaming infrastructure, and streaming.
Why the others fail:
minimal latency — grammatically correct but not the fixed phrase engineers use
zero latency — physically impossible; implies no delay at all, which is used only hyperbolically
reduced latency — describes an improvement, not a design goal or system property
The canonical pair: high throughput + low latency — these two often appear together as competing performance concerns.
Common collocations:
low-latency network
optimise for low latency
low-latency trading system
latency-sensitive workload
3 / 5
A distributed systems engineer explains storage replication:
"In our multi-region setup, replicas will be ___ consistent — reads may return slightly stale data, but all nodes will converge to the same state over time."
Which adjective phrase describes this well-known CAP theorem trade-off?
Eventual consistency is a fundamental distributed systems concept. It means that, given no new updates, all replicas will eventually converge to the same value — but at any given moment, different nodes may return different data. This is the consistency model used by DynamoDB, Cassandra, CouchDB, and DNS.
Why the others fail:
temporarily consistent — not a technical term; inconsistency sounds like a bug rather than a design choice
loosely consistent — not used in this technical sense
progressively consistent — not a recognised term
The CAP theorem context: Eventual consistency is the result of choosing Availability + Partition tolerance over strong Consistency (the C in CAP).
Common collocations:
eventually consistent store
eventual consistency model
BASE vs ACID (BASE = Basically Available, Soft state, Eventually consistent)
strong consistency vs eventual consistency
4 / 5
A system design document states:
"The payment processor must be ___ — if a charge request is duplicated due to a network retry, the customer must never be billed twice."
Which single-word adjective describes an operation that produces the same result no matter how many times it is executed?
Idempotent is the precise term. An idempotent operation can be applied multiple times without changing the result beyond the first application. This is critical for API design, payment systems, and distributed systems where retries are common. HTTP GET, PUT, and DELETE are defined as idempotent; POST is not.
Why the others are close but wrong here:
atomic — an atomic operation either completes fully or not at all (all-or-nothing). It prevents partial failures but does not address duplicate execution.
deterministic — always produces the same output for the same input, but does not address the "safe to repeat" property. A deterministic function can still cause side effects when repeated.
stateless — does not store state between requests. A stateless service can still have non-idempotent endpoints.
Common collocations:
idempotent API endpoint
make the operation idempotent
idempotency key (Stripe uses this pattern)
idempotent consumer (in message queues)
5 / 5
An architect explains a microservices design choice:
"Each worker node must be ___ — it should hold no session data between requests. All required context comes in the request itself."
Which adjective describes a component that retains no information between calls?
Stateless is the correct term. A stateless component does not store any client session data between requests. Each request contains all the information needed to process it. This is the foundation of horizontal scalability — if no node holds session state, any node can handle any request.
Why this matters for reliability:
Stateless services can be scaled horizontally without sticky sessions
Any replica can replace a failed one immediately
Load balancers can route requests freely
The opposite:stateful — the component tracks state between requests (e.g., a WebSocket connection, a database).
Common collocations:
stateless authentication (JWT tokens carry state in the token itself)
stateless REST API
stateless function
stateless vs stateful
stateless worker
Related concepts: RESTful APIs are defined as stateless by the REST architectural constraints (Roy Fielding, 2000).