Glossary

The time elapsed from when a request is initiated to when a response is received. In the context of software dependencies, latency includes network round-trip time, server processing time, and any queuing delay. Usually measured in milliseconds.

The latency experienced by requests in the slow end of the distribution — typically the 95th, 99th, or 99.9th percentile. Tail latency is disproportionately important because in a system that makes many parallel requests, the overall response time is bounded by the slowest one. Systems that look fast at p50 can still have serious problems hiding in the tail.

The 50th percentile latency. Half of all requests complete faster than this value, and half complete slower. The median is a better measure of typical latency than the mean because it is not skewed by rare very-slow outliers. slowdep uses p50 as one of the two parameters for its lognormal model.

The 95th percentile latency. 95% of requests complete faster than this value; 5% are slower. A useful signal for "what does a somewhat unlucky user experience?" Production SLOs often target p95 as a balance between coverage and the noisiness of very high percentiles.

The 99th percentile latency. 99% of requests complete faster than this value; 1 in 100 is slower. p99 is the standard "danger zone" benchmark. If your timeout is shorter than the p99 latency of a dependency, 1% of calls will time out. slowdep uses p99 as its second parameter, alongside p50, to fit the lognormal distribution.

The 99.9th percentile latency — one in a thousand requests falls at or above this value. At high traffic volumes, p999 outliers become common in absolute terms. For example, at 10,000 requests per second, roughly 10 requests per second hit the p999 latency. slowdep caps sampled latency at p99 × 3 as a practical approximation of this tail.

Random variation in latency from call to call. A service with low jitter responds in a consistent, predictable time. A service with high jitter has widely varying response times even under stable load. Real network services always have some jitter. slowdep's lognormal distribution naturally produces jitter — no two calls take exactly the same amount of time.

A probability distribution where the logarithm of the variable is normally distributed. Latency in real systems follows a lognormal shape: most values cluster near the median, the distribution is right-skewed (there's a floor near zero but no ceiling), and there's a long tail of occasional slow outliers. slowdep samples from a lognormal distribution parameterized by p50 and p99 to produce realistic latency values.

A mathematical technique for generating pairs of independent, standard normally-distributed random numbers from pairs of uniform random numbers. slowdep uses the Box-Muller transform internally to sample from the lognormal distribution. Given two uniform random values u1 and u2, it computes a normal sample as sqrt(-2 * ln(u1)) * cos(2p * u2), then exponentiates it to get the final latency.

A cache that already contains the data being requested, allowing the request to be served without a round trip to the underlying store. Warm-cache latency is typically much lower than cold-cache or cache-miss latency. The redis preset in slowdep (p50: 1ms, p99: 20ms) approximates a warm in-process or network cache.

The elevated latency experienced by the first request after a service, connection, or cache starts up — before JIT compilation, connection pooling, or caching have warmed up. Cold starts can be orders of magnitude slower than steady-state latency and are a common source of timeout failures in serverless and containerized environments.

Automatically re-attempting a failed request. Retries are a primary defense against transient errors — short-lived failures that succeed if tried again a moment later. slowdep's errorRate option injects transient errors that retries should recover from, allowing you to test your retry logic under realistic conditions.

A retry strategy where the wait time between retries grows exponentially with each attempt — e.g., 100ms, 200ms, 400ms, 800ms. Exponential backoff prevents retry storms where many clients hammer a struggling service simultaneously. Usually combined with jitter (see below) to spread retry load across time.

In the context of retry backoff, jitter means adding randomness to the wait time between retries. Without jitter, all clients that failed at the same time retry at the same time, creating a thundering-herd problem. With jitter, retries are spread across a time window, reducing the load spike on the recovering service. This is distinct from latency jitter but shares the same root concept: randomness reduces coordination.

A resilience pattern that stops sending requests to a dependency after a threshold of failures, instead immediately returning an error or fallback response. After a recovery timeout, the circuit allows a probe request through. If it succeeds, the circuit closes and normal traffic resumes. Circuit breakers prevent cascade failures caused by a slow or failed downstream service from consuming all threads or connections in the calling service.

A maximum duration a caller is willing to wait for a response. If the dependency does not respond within the timeout, the call fails with a timeout error. Setting timeouts correctly requires knowing the p99 latency of the dependency. If the timeout is shorter than p99, about 1% of calls will time out even under normal conditions.

A point in time (as opposed to a duration) by which a request must complete. Deadlines propagate through a call chain — a 500ms deadline set at the API gateway applies to the entire chain of service calls, including database queries. If 200ms is spent in application logic before calling a database, the database has at most 300ms. Deadline-aware systems cancel in-flight requests when the deadline passes.

A resilience pattern that isolates resources (connection pools, thread pools, queues) so that a failure in one dependency cannot exhaust the resources of the entire system. Named after the watertight compartments in ship hulls. In practice: give each downstream dependency its own connection pool with a cap, so a slow database cannot consume all connections and block requests to unrelated services.

Deliberately introducing errors, latency, or resource exhaustion into a system to test how it responds. slowdep's errorRate option is a form of fault injection — it causes a fraction of calls to fail with a transient error, surfacing gaps in error handling and retry logic before they appear in production.

The practice of intentionally introducing failures into a system — in staging or production — to verify that it remains resilient. Pioneered at Netflix with the Chaos Monkey tool. slowdep is a lightweight, code-level form of chaos engineering targeted at individual dependency interactions during development and testing, not full production chaos experiments.

Testing a system's ability to withstand and recover from adverse conditions: latency spikes, transient errors, dependency failures, and resource exhaustion. slowdep enables resilience testing at the unit and integration test level by making dependency latency and errors controllable and reproducible, without requiring a real infrastructure fault to occur.