Architecture & capacity review

How it's built, where it breaks, and what you can't see.

A fixed-scope, end-to-end read of your application or service, covering architecture, capacity, cost, scalability, security and instrumentation, ending in a written verdict rather than a workshop.

Book a review

Scope

Your whole system, not one component of it.

Most reviews are commissioned about the thing that's currently hurting, and stop there. The useful version looks at the system that produced the symptom, because a capacity problem is often an architecture decision, a cost problem is usually a capacity decision, and a security finding is often an instrumentation gap that let it go unnoticed.

So this covers the application and the infrastructure it runs on, whoever built it and wherever it runs. We're not reviewing it to sell you a migration.

Six dimensions

Architecture
Capacity
Cost
Scalability
Security
Instrumentation

Weighted to what matters for your system. A review of a pre-revenue service and one of a regulated platform are not the same engagement.

What gets reviewed

In detail.

Architecture

How the system is put together, and what that costs you later.

Service boundaries, coupling, and where a change in one place breaks another
Data flow and ownership: who writes what, and who depends on it
Failure domains, and what actually happens when one goes
State: where it lives, what's replicated, and what can't be rebuilt
Dependencies you'd struggle to replace

Capacity

How much headroom you have, measured rather than assumed.

Current utilisation against provisioned capacity, per tier of the stack
Growth modelled on your real numbers, not a rule of thumb
Where you run out first, and how long you have
Over-provisioning: capacity you're holding and not using

Cost

Where the money goes, and which parts grow on their own.

Spend broken down by service and environment, not just by invoice line
Cost per unit of the thing you actually sell: per request, customer or tenant
Which costs scale with usage, which with revenue, and which with neither
The quiet growers: egress, storage tiering, retention, orphaned resources
What three times the traffic costs before anything is optimised
Commitments and reservations, weighed against the flexibility they cost you

Scalability

What breaks at three times the load, and at ten.

Bottlenecks under load: connection pools, single writers, lock contention
What's stateful that shouldn't be, and what can't be scaled horizontally
Caching: what's cached, what should be, and what goes stale dangerously
Backpressure and degradation: does it slow down or fall over

Security

The exposure, from the outside in and the inside out.

Attack surface: what's reachable, from where, and why
Authentication and authorisation, including between your own services
Secrets: how they're stored, rotated, and who can read them
Dependency and supply-chain exposure, and how you'd find out about a CVE
Data handling: what's collected, where it goes, and what regulation applies

Instrumentation

Whether you'd know, and how fast.

Coverage across logs, metrics and traces, and the gaps between them
Whether an incident can be diagnosed from what you already collect
Alert quality: what fires, what's ignored, and what should exist
Service level objectives, and whether they reflect what users feel
Incident readiness: runbooks, escalation, and who knows what

What a finding looks like

Specific enough to act on.

Findings name the thing, the consequence, and the fix, with the number that makes it urgent or not, and an honest estimate of the work. A report full of "consider reviewing your caching strategy" is one nobody acts on.

Sample finding · redacted

Checkout writes and reporting reads share one primary

All writes and every reporting query run against the same primary instance. Reporting already accounts for roughly 40% of query time at peak; at three times current traffic the reporting load alone exceeds today's capacity. The failure mode isn't a slow dashboard. It's checkout timing out because someone opened a monthly report.

Fix: move reporting to a read replica and set a statement timeout on the reporting role. About a week, no schema change, no application rewrite.

Deliverables

What you're left holding.

Everything is written down and yours to keep, including the capacity model, so you can rerun it next year without us.

A written report you can circulate to engineering and to the board
A capacity model with your numbers in it, that you can rerun later
A prioritised list of findings, each costed by effort
A readout session with the people who'd do the work

Afterwards

Two things usually follow.

We deliver the fixes

The prioritised list is quotable as scoped work. Most teams commission a review because they want the problems gone, not because they want a document, so the follow-on is priced from the findings rather than guessed at up front.

Talk to us

It becomes the basis for support

If you want us covering the estate afterwards, this review is how we learn it. We won't commit to response targets against a system nobody on our side has examined.

Ongoing support

Book a review.

Fixed scope, custom quote, and a written verdict at the end. The scoping call establishes how big the system is and which dimensions matter most.

Book a review Other engagements