---
title: "Glossary"
description: "Terms that the cards link to, with a note on why a reviewer cares."
canonical: "https://goodcodereview.com/glossary"
updated: "2026-10-25"
---

# Glossary

## API gateways

A reverse proxy for APIs. It handles auth, routing, quotas, and request shaping at one entry point.

**Why a reviewer cares.** Per-tenant quotas and 429 behaviour are often configured here. Check that they exist somewhere.

**Checks.** `svc-rate-limit-quota`

## Autoscaling

Adding or removing capacity automatically from load signals.

**Why a reviewer cares.** Scaling hides overload only until a limit, such as a pool size or a quota, is hit.

## Backups

Copies of data kept to restore after loss.

**Why a reviewer cares.** Only a restore test proves a backup.

## Blue-green deployment

Two full environments. Traffic switches from the old one to the new one in a single step.

**Why a reviewer cares.** The switch is fast to reverse, but it tests the release all at once, unlike a canary.

**Checks.** `prod-canary-staged-rollout`

## CAP theorem

During a network partition, a system must choose between consistency and availability.

**Why a reviewer cares.** This trade-off sits behind every multi-node design decision.

## CDN

A network of edge servers that cache and serve content near users.

**Why a reviewer cares.** Cache keys and TTLs decide which stale content users see.

## Chaos engineering

Injecting failure on purpose to see how a system behaves.

**Why a reviewer cares.** Cheap forms, such as disabling the cache, expose hidden dependencies.

## Clean Code

Robert Martin's style guide. It favours small functions and good names over comments.

**Why a reviewer cares.** Ousterhout disputes it on function length and comments. Treat splitting a function as a local decision.

## Clock skew

Machines that disagree about the time.

**Why a reviewer cares.** TTL-based locks and expiry logic depend on clocks. Use monotonic time at a minimum.

**Checks.** `sys-lock-fencing`

## Cold starts

Slow first requests after a deploy, restart, or scale-up, while caches and runtimes are empty.

**Why a reviewer cares.** Cold caches can flood the dependency with requests.

## CORS

Browser rules for which origins may call an API.

**Why a reviewer cares.** An allow-list that is too broad weakens browser protections.

## Cost optimization

Cutting spend without changing the outcome.

**Why a reviewer cares.** Reviewers weigh cost against reliability. The research has no source for this entry.

## CSRF

Tricking a logged-in browser into sending a request the user did not intend.

**Why a reviewer cares.** State-changing endpoints need a defence. Look for one.

## DDD

Domain-driven design: modelling code around the business domain and its language.

**Why a reviewer cares.** Stub. The research notes do not cover it.

## DDoS protection

Absorbing or filtering floods of traffic.

**Why a reviewer cares.** App-level quotas and cheap load shedding complement network defences.

**Checks.** `svc-rate-limit-quota`

## Deadlocks

Two or more actors that each wait on a lock another one holds.

**Why a reviewer cares.** A timeout on lock acquisition turns a hang into an error.

## Disaster recovery

Restoring service after a major loss.

**Why a reviewer cares.** A plan that was never tested is a guess.

## Distributed tracing

Following one request across services by a shared trace id.

**Why a reviewer cares.** A trace id on every wide event lets reviewers connect symptoms to causes.

## Distributed transactions

One logical operation that spans several services or stores and has no single commit.

**Why a reviewer cares.** Without a saga or an equivalent, a partial failure leaves the data inconsistent.

## DNS

The system that maps names to addresses.

**Why a reviewer cares.** Caching and failures show up as odd timeouts.

## Docker

Container images and runtimes that package an app with its dependencies.

**Why a reviewer cares.** A container is reproducible only if the build is hermetic and its inputs are pinned.

## Edge caching

Caching responses near the user, outside the origin.

**Why a reviewer cares.** Invalidation is the hard part. Versioned entries make it easier.

**Checks.** `sys-cache-bounds-invalidation`

## Encryption at rest

Encrypting stored data.

**Why a reviewer cares.** Check what the encryption covers and who holds the keys.

## Encryption in transit

Encrypting data while it crosses a network.

**Why a reviewer cares.** TLS usually provides it.

## Error budgets

The failure allowance that an SLO implies.

**Why a reviewer cares.** Canary size and rollout speed should fit within the budget.

**Checks.** `prod-canary-staged-rollout`

## Event-driven architecture

Components communicate by emitting and reacting to events instead of calling each other directly.

**Why a reviewer cares.** Failure moves into queues and redelivery. Look for idempotent handlers and dead-letter handling.

## Eventual consistency

Replicas converge if no new writes arrive, but they can disagree until then.

**Why a reviewer cares.** Code that assumes read-your-writes can break without any error.

## Failover

Switching to a standby when the primary fails.

**Why a reviewer cares.** An overlap window can leave two primaries active.

## Fowler's Smells

Fowler's catalogue of code smells that point to a needed refactoring.

**Why a reviewer cares.** Stub. The 12 intended smells were not named. Confirm the list, then map each smell to a check.

## Garbage collection

Automatic reclaiming of unreachable memory.

**Why a reviewer cares.** The collector can reclaim some objects early, such as unreferenced asyncio tasks. Catch these in review.

## gRPC

A typed RPC framework over HTTP/2.

**Why a reviewer cares.** Every call still needs a deadline.

**Checks.** `svc-timeouts`

## Grug

A folk essay that argues for simple code and distrust of complexity.

**Why a reviewer cares.** Stub. The research notes do not cover it. Add a source before citing it.

## Helm charts

Templated packages of Kubernetes manifests.

**Why a reviewer cares.** Template logic can hide what ships.

## Horizontal scaling

Adding more instances.

**Why a reviewer cares.** State must live outside the instance, and the work must be safe to run on many nodes.

## HTTP/2 & HTTP/3

Newer HTTP versions that multiplex requests on one connection. HTTP/3 uses QUIC.

**Why a reviewer cares.** Connection reuse changes how pools and timeouts behave.

## IAM

Rules for who or what may take which action on which resource.

**Why a reviewer cares.** Least privilege applies to CI token permissions and service roles.

**Checks.** `code-workflow-supply-chain`

## Infrastructure as code

Describing infrastructure in versioned files.

**Why a reviewer cares.** Review plans the way you review code.

## JWT rotation

Replacing signing keys or tokens on a schedule.

**Why a reviewer cares.** Stub. The research has no source for this entry.

## Kubernetes

A scheduler that runs containers, restarts them, and rolls out new versions.

**Why a reviewer cares.** Probes and rollout settings decide whether a bad release spreads or stops.

**Checks.** `prod-canary-staged-rollout`

## Latency

Time from request to response.

**Why a reviewer cares.** Do not mix the latency of failed requests with that of successful ones.

**Checks.** `prod-alerts-symptoms-golden-signals`

## Liveness and readiness probes

A liveness probe says the process is alive. A readiness probe says it should receive traffic.

**Why a reviewer cares.** What each probe checks decides whether failures cascade.

## Load balancing

Spreading requests across several backends and using health signals to skip unhealthy ones.

**Why a reviewer cares.** The health check wired to the balancer decides which hosts stay in rotation. A check that probes a shared dependency can empty the whole pool.

## Long polling

The client sends a request, and the server holds it open until data arrives or a timeout expires.

**Why a reviewer cares.** Review the timeouts on both ends and the reconnect behaviour.

## Multi-region deployment

Running a service in several geographic regions.

**Why a reviewer cares.** Isolation limits the blast radius, but data and config shared across regions can still fail together.

## Network partitions

Parts of a system that cannot reach each other.

**Why a reviewer cares.** Leader and lock code must stay safe during a partition.

## OAuth

A protocol for delegated access that uses tokens instead of passwords.

**Why a reviewer cares.** Review the scopes and the token handling.

## On-Call

Engineers who take turns responding to alerts.

**Why a reviewer cares.** Alerts that page on non-symptoms wear out the people on call.

**Checks.** `prod-alerts-symptoms-golden-signals`

## Optimistic locking

Write only if the version has not changed since the read. Retry on conflict.

**Why a reviewer cares.** The AWS leader-election page suggests trying it before electing a leader.

**Checks.** `sys-lock-fencing`

## P99 latency

The latency that 99% of requests beat.

**Why a reviewer cares.** Means hide it. Use bucketed distributions.

**Checks.** `prod-alerts-symptoms-golden-signals`

## Partitioning

Splitting one table or dataset into parts inside a single system.

**Why a reviewer cares.** It affects locks and migrations on large tables.

## Pessimistic locking

Take a lock before working so that others wait.

**Why a reviewer cares.** Lock duration and mode decide who gets blocked, for example during migrations.

## Postmortems

Written reviews of an incident and its follow-ups.

**Why a reviewer cares.** Ask whether a fix addresses the cause that the postmortem names.

## Production incidents

Unplanned events that harm users.

**Why a reviewer cares.** Many review checks exist because a past incident showed the failure.

## Pub/Sub

Producers publish to topics, and each subscriber receives its own copy.

**Why a reviewer cares.** Delivery is usually at-least-once, so consumers must tolerate duplicates.

## Query optimization

Changing queries or the schema so that the database does less work for the same result.

**Why a reviewer cares.** A claimed speedup needs numbers or a query plan, not a hunch.

## Race conditions

Behaviour that depends on the unplanned timing of concurrent operations.

**Why a reviewer cares.** Reading the code rarely shows them. Ask what guards the shared state.

**Checks.** `sys-lock-fencing`

## Read replicas

Copies of a database that serve reads while a primary takes the writes.

**Why a reviewer cares.** Replica lag means that a read after a write can return stale data.

## Replication

Keeping copies of data on several nodes.

**Why a reviewer cares.** It raises the consistency and failover questions that a review must answer.

## Reverse proxies

A server that receives client traffic and forwards it to backends. It often adds TLS, caching, or routing.

**Why a reviewer cares.** Check which layer owns timeouts, retries, and headers, so that none is applied twice.

## Semantic versioning

MAJOR.MINOR.PATCH numbers that signal compatibility.

**Why a reviewer cares.** Observable behaviour counts as API even when undocumented.

**Checks.** `chg-breaking-change-taxonomy`

## Server-sent events

A one-way stream from the server to the browser over HTTP.

**Why a reviewer cares.** Like any open stream, it needs a timeout and a way to resume.

## Serverless limits

Quotas on duration, memory, concurrency, and payload size for functions-as-a-service.

**Why a reviewer cares.** Code that ignores them fails only in production.

## Service discovery

How a service finds the current addresses of its dependencies.

**Why a reviewer cares.** Stale or missing entries show up as timeouts, so every call needs a bound.

## Sharding

Splitting data across databases by key.

**Why a reviewer cares.** The shard key is hard to change later, so scrutinize it in design review.

## SLIs

The measured quantity that an SLO targets, such as error rate or latency.

**Why a reviewer cares.** A good SLI measures a symptom that users feel.

**Checks.** `prod-alerts-symptoms-golden-signals`

## SLOs

A target for a service-level indicator, such as a success rate over a period.

**Why a reviewer cares.** They turn alert and rollout decisions into numbers.

## SOLID

Five object-design principles: single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion.

**Why a reviewer cares.** Only the Liskov rule has a source in the research. The other four need one.

## Tail latency

The slow end of the latency distribution.

**Why a reviewer cares.** Fan-out calls make rare slow requests common.

**Checks.** `prod-alerts-symptoms-golden-signals`

## TCP and UDP

TCP gives ordered, reliable streams. UDP sends unordered datagrams.

**Why a reviewer cares.** The choice shapes how retries and packet loss are handled.

## TDD

Writing a failing test first, then the code, then refactoring.

**Why a reviewer cares.** The research leaves the TDD dispute unresolved. Do not fail a change for skipping TDD.

## Terraform

A tool that applies declarative infrastructure definitions.

**Why a reviewer cares.** Review the plan output as well as the diff.

## Thermo-nuclear points

Placeholder for a list that nobody supplied.

**Why a reviewer cares.** Add rows when the points are available.

## Thread safety

Code that stays correct when several threads call it at once.

**Why a reviewer cares.** Ask which state is shared and what protects it.

## Throughput

Work completed per unit of time.

**Why a reviewer cares.** A change can raise throughput and hurt latency.

## TLS

Encryption and server authentication for network connections.

**Why a reviewer cares.** Disabled certificate verification is a classic defect to catch in review.

## Vertical scaling

Giving one instance more CPU or memory.

**Why a reviewer cares.** It has a ceiling and a single point of failure.

## WAF

A filter in front of a web app that blocks known-bad requests.

**Why a reviewer cares.** It reduces risk but does not replace fixing injection flaws in code.

## Webhooks

HTTP callbacks that a service sends when an event occurs.

**Why a reviewer cares.** Delivery repeats on failure, so receivers must be idempotent.

**Checks.** `svc-idempotency-key`, `svc-retry-policy`

## WebSockets

A long-lived two-way connection between client and server, over one upgraded HTTP connection.

**Why a reviewer cares.** Connections hold server resources, so check the bounds and the cleanup.