Architecture Review Before Release: Catch the Risks While They Are Cheap

Why review before, not after

Teams usually learn about architectural weakness the expensive way: in production, in front of customers. The signs were often visible earlier. A new service with no health check. A database with a single instance and no tested restore. A queue with no dead-letter handling. A feature that doubles traffic to a downstream service nobody sized. Each was cheap to fix on a whiteboard and costly to fix during an incident.

A pre-release review inserts a short, focused look at the change before it ships. It is included in our Managed DevOps service because the people who will run the system at 3am are well placed to ask how it will fail.

What good looks like

A good review is not a gate that slows teams down or an audit that produces a binder. It is a conversation with a clear output:

• A shared understanding of what is shipping and what could go wrong.
• A short list of findings ranked by severity.
• Specific, buildable recommendations, not abstract advice.
• A decision made by the owners with full information.
• A note of what was accepted as risk, and why.

Frameworks such as the AWS Well-Architected pillars (operational excellence, security, reliability, performance efficiency, cost optimisation, sustainability) are useful checklists, and we borrow their questions. We apply them to the change, not to your whole estate.

How the review works

Scope first

Before reading any diagram we ask four questions. What is changing? How many users or how much data does it touch? What happens if it fails completely? How quickly could we undo it? The answers decide depth. A cosmetic release needs minutes; a new payment integration deserves a day of care.

Trace the failure paths

The core technique is simple: take each component and ask what happens when it is slow, down, wrong or full. For a request path this means walking from the load balancer to the database and back:

1. What are the timeouts at each hop, and are they shorter as you go deeper?
2. Are retries bounded, with backoff and jitter, so a slow dependency does not become a retry storm?
3. Is there a circuit breaker or graceful degradation, or does one failure cascade?
4. Can the service scale horizontally, or does it hold state that stops it?
5. Which dependencies are single points of failure, including a single availability zone?

A small example of what we look for in a Kubernetes manifest is the set of fields that make a release survivable:

spec:
  replicas: 3
  strategy:
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      containers:
        - name: api
          readinessProbe:
            httpGet: { path: /healthz/ready, port: 8080 }
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits: { memory: "512Mi" }

Missing probes, a single replica or absent requests are typical findings, each simple to fix before launch. Related background is in our EKS guide.

Operability checklist

Many teams review design carefully and forget operations. We check that the release will be runnable:

• Observability: metrics, logs and traces exist for the new path, and dashboards show its health. See monitoring.
• Alerts: at least one symptom-based alert, with an owner.
• Runbooks: a procedure for the likeliest failures, per our runbooks approach.
• Rollback: tested, with a plan for data changes, which are harder to undo than code. Strategies such as blue-green deployment help, but only if schema changes are backward compatible.
• Capacity: expected load fits within tested limits; see capacity planning and load testing.
• Security: least-privilege roles, secrets handling, and public exposure, aligned with the security baseline.
• Infrastructure as code: all new resources are in code and reviewed; see Terraform maintenance.
• Cost: a rough estimate of run cost, so there is no surprise bill.

Writing findings that get fixed

Findings are only useful if people act on them. Each of ours includes a short title, the risk in plain language, the evidence, a severity, a recommended fix and an effort estimate. Severity has three levels:

We avoid long lists of trivia. Ten findings that matter beat sixty that do not.

Decisions and trade-offs

Speed versus thoroughness. A startup racing to a deadline cannot review everything. We focus on irreversible and high-blast-radius risks, such as data stores, authentication, payments and anything that is hard to roll back.

Advice versus authority. We recommend; you decide. If you accept a risk, we record it with an owner and a review date so it does not vanish.

Review inside the team versus outside. Your engineers know the product best; an outside reviewer brings pattern memory from other systems and has no attachment to the design. The combination works best, and the walkthrough is collaborative.

When not to buy this. For small, easily reversible changes, a peer review and a good rollback plan are enough. A formal review pays off for launches, migrations and new data stores.

Common failure modes

• Review too late. A week before launch, big changes are unrealistic. Involve us at the design stage for major work.
• Design only. Beautiful diagrams, no alerts, no runbook.
• Ignoring data. Code can be rolled back; destructive migrations cannot.
• Hidden dependencies. A third-party API with low rate limits discovered on launch day.
• No follow-up. Findings are written and never tracked. We carry them into the weekly check-in.

Delivery and handover

You receive the written findings, the checklist used, and a short summary suitable for a launch meeting. We track open items until closed and watch the release closely, including staying engaged through the first hours after go-live. If the change involves a platform move, our cloud migration service covers that work in depth.

How to tell it is working

After a few cycles you should see launches with fewer rollbacks, fewer incidents in the first week of new features, blockers found early rather than late, and engineers who ask the failure-path questions themselves. To book a review ahead of your next release, contact us.

References

• Reliable Product Launches at Scale, Google SRE Book
• AWS Well-Architected Framework, AWS documentation
• Azure Well-Architected Framework, Microsoft Learn