Glossary

Latency budget: maximum end-to-end time for a user path. Stack DNS, TLS, gateways, RPC, and DB hops so the sum stays under your SLA or SLO target.

SLA vs SLO: SLA is the customer contract; SLO is the internal numeric target and error budget so you miss SLO before breaching the public SLA.

p50 latency is the median request duration—half faster, half slower. Pair it with p99 because a good median still hides painful tail outliers.

p99 latency: 99th percentile request duration. SREs use tail percentiles for SLOs—averages hide outliers users still hit in production traffic.

Latency headroom: gap between measured path latency and your SLO ceiling. Capacity and rate limits preserve headroom by preventing queue blowups.

Cold start (serverless): extra latency while FaaS provisions or warms a runtime. Model it as a hop when traffic is sparse or scales from zero.

Cross-AZ latency: inter-zone networking inside one cloud region. Replicated systems like Kafka add RTT when leaders and followers span zones.

Fixed window rate limiting counts requests in fixed time buckets. Simple, but aligned clients can spike to roughly double the nominal limit at edges.

Sliding window rate limiting rolls request counts over time to reduce fixed-window boundary spikes—more state, usually fairer client enforcement.

Leaky bucket shaping outputs traffic at a steady drip, queueing or dropping bursts—contrast with token buckets that accrue idle burst credit.

Token bucket rate limiting: steady refill plus burst capacity. Common at API gateways; pairs with sliding and fixed windows for fair client throttling.

Retry jitter randomizes backoff so many clients do not retry in lockstep. Use it with exponential backoff to dampen thundering herds during incidents.

Exponential backoff grows retry delays multiplicatively to shed load during outages. Add jitter so retries from many clients do not line up in time.

Retry storm: synchronized retries multiply traffic until backends fail again. Mitigate with jitter, exponential backoff, budgets, and edge rate limits.

HTTP 429 Too Many Requests means the server is rate limiting you. Slow down, honor Retry-After when present, and respect RateLimit response headers.

IETF RateLimit header draft standardizes quota signaling for HTTP clients. Many production APIs still expose legacy X-RateLimit-* header families.

Kafka partition: ordered log shard inside a topic. Consumer group parallelism is capped by partition count—central to lag math and cluster sizing.

Kafka consumer lag measures how far committed offsets trail the log end per partition. Rising lag means consumers cannot keep up or are stuck.

Kafka consumer group: cooperating consumers share partitions—at most one active consumer per partition so per-partition ordering stays intact.

Kafka consumer offset is the next record position in a partition. Commits define restart points and feed lag as the gap to the current log end.

Effective Kafka consumers equal min(running consumers, partitions). Extra consumer instances stay idle until you add partitions for more parallelism.

Kafka consumer poll loop drives fetch and heartbeats via poll(). If processing exceeds max.poll.interval.ms, the group may revoke your partitions.

Kafka consumer rebalance moves partition assignments when members join or leave. It pauses consumption briefly and frequent churn can grow consumer lag.

Kafka replication factor is how many brokers store each partition replica. It enables failover and multiplies storage plus replication network cost.

Kafka log retention sets how long or how large topic data may grow. It bounds disk use and how far slow consumers can lag before data expires.

Kafka producer compression trades CPU for smaller batches on disk and wire. Pick a codec and ratio that match your payload and broker capacity.

Throughput vs bandwidth (Kafka): throughput is achieved bytes per second; bandwidth is link or disk capacity—size brokers above sustained load.

Semantic Versioning (SemVer) uses MAJOR.MINOR.PATCH to signal API compatibility: breaking, backward compatible features, and non-breaking fixes.

API version bumps under SemVer: patch for fixes, minor for compatible features, major for breaks—communicate consumer impact in release notes.

API breaking change: clients fail or misbehave without updates—field removal, stricter validation, or error semantics usually need a major bump.

Calendar Versioning (CalVer) ties versions to release dates. The calendar alone does not imply SemVer compatibility—document breaking changes explicitly.