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
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.
Copies of data kept to restore after loss.
Why a reviewer cares. Only a restore test proves a backup.
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
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.
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.
Injecting failure on purpose to see how a system behaves.
Why a reviewer cares. Cheap forms, such as disabling the cache, expose hidden dependencies.
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.
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
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.
Browser rules for which origins may call an API.
Why a reviewer cares. An allow-list that is too broad weakens browser protections.
Cutting spend without changing the outcome.
Why a reviewer cares. Reviewers weigh cost against reliability. The research has no source for this entry.
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.
Domain-driven design: modelling code around the business domain and its language.
Why a reviewer cares. Stub. The research notes do not cover it.
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
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.
Restoring service after a major loss.
Why a reviewer cares. A plan that was never tested is a guess.
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.
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.
The system that maps names to addresses.
Why a reviewer cares. Caching and failures show up as odd timeouts.
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.
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
Encrypting stored data.
Why a reviewer cares. Check what the encryption covers and who holds the keys.
Encrypting data while it crosses a network.
Why a reviewer cares. TLS usually provides it.
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
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.
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.
Switching to a standby when the primary fails.
Why a reviewer cares. An overlap window can leave two primaries active.
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.
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.
A typed RPC framework over HTTP/2.
Why a reviewer cares. Every call still needs a deadline.
Checks. svc-timeouts
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.
Templated packages of Kubernetes manifests.
Why a reviewer cares. Template logic can hide what ships.
Adding more instances.
Why a reviewer cares. State must live outside the instance, and the work must be safe to run on many nodes.
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.
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
Describing infrastructure in versioned files.
Why a reviewer cares. Review plans the way you review code.
Replacing signing keys or tokens on a schedule.
Why a reviewer cares. Stub. The research has no source for this entry.
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
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
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.
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.
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.
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.
Parts of a system that cannot reach each other.
Why a reviewer cares. Leader and lock code must stay safe during a partition.
A protocol for delegated access that uses tokens instead of passwords.
Why a reviewer cares. Review the scopes and the token handling.
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
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
The latency that 99% of requests beat.
Why a reviewer cares. Means hide it. Use bucketed distributions.
Checks. prod-alerts-symptoms-golden-signals
Splitting one table or dataset into parts inside a single system.
Why a reviewer cares. It affects locks and migrations on large tables.
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.
Written reviews of an incident and its follow-ups.
Why a reviewer cares. Ask whether a fix addresses the cause that the postmortem names.
Unplanned events that harm users.
Why a reviewer cares. Many review checks exist because a past incident showed the failure.
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.
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.
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
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.
Keeping copies of data on several nodes.
Why a reviewer cares. It raises the consistency and failover questions that a review must answer.
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.
MAJOR.MINOR.PATCH numbers that signal compatibility.
Why a reviewer cares. Observable behaviour counts as API even when undocumented.
Checks. chg-breaking-change-taxonomy
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.
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.
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.
Splitting data across databases by key.
Why a reviewer cares. The shard key is hard to change later, so scrutinize it in design review.
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
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.
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.
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 gives ordered, reliable streams. UDP sends unordered datagrams.
Why a reviewer cares. The choice shapes how retries and packet loss are handled.
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.
A tool that applies declarative infrastructure definitions.
Why a reviewer cares. Review the plan output as well as the diff.
Placeholder for a list that nobody supplied.
Why a reviewer cares. Add rows when the points are available.
Code that stays correct when several threads call it at once.
Why a reviewer cares. Ask which state is shared and what protects it.
Work completed per unit of time.
Why a reviewer cares. A change can raise throughput and hurt latency.
Encryption and server authentication for network connections.
Why a reviewer cares. Disabled certificate verification is a classic defect to catch in review.
Giving one instance more CPU or memory.
Why a reviewer cares. It has a ceiling and a single point of failure.
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.
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
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.