Signs your architecture is starting to slow your growth

Software architecture problems rarely arrive as one big outage. They arrive as small, steady changes: a page that takes a little longer each month, a release that needs a hotfix, estimates that keep getting padded. Each one is easy to explain away. Together they say the system you launched with no longer fits the business you have become.

Each of these signs shows up in a number you can already collect. This piece pairs five signs with the measure that tells you whether you have an architecture limit or an ordinary bad week, and ends with the order we would fix things in.

Speed also has a price. In April 2026 Shopify published an analysis of actively selling stores: for every 100 milliseconds slower a store loaded its main content, conversion tended to be about 3.5% lower. Shopify itself calls this a correlation, not proof of cause, and it covers online stores, so read it as a sense of scale.

The five signs and what to measure

Start with the instruments. The four golden signals from Google’s Site Reliability Engineering book are latency, traffic, errors and saturation. For delivery speed, DORA defines five measures, including change lead time and change fail rate. Here is how they map to the signs:

Four of those terms in plain words:

• Saturation is how full your busiest resource is: processor, memory or database connections.
• The 99th percentile is the response time that 99 out of 100 requests come in under. It shows how bad the slow ones get.
• Change lead time is how long a finished change waits before customers get it.
• Change fail rate is the share of releases that need an urgent fix.

None of these needs a new tool. Most of the numbers are already in your cloud or hosting dashboard (your cloud provider’s console or your host’s control panel), your database or your deployment history, and cost comes from your bill. The rest of this piece takes the signs one at a time.

Pages get slower as data grows

When response times climb month after month and traffic hasn’t, look at the data layer first. That is common, not universal, so measure before you decide.

Your database can show you where the time goes. PostgreSQL’s pg_stat_statements module records how many times each SQL statement ran and the total and average time it took. It has to be switched on, which needs a server restart. Other databases have their own equivalents.

Sort by total time, not by the slowest single query. These illustrative numbers show why:

Sorting by total time puts A first, even though each run is quick. A is what keeps your database busy all day. B is still worth fixing if customers wait on it, but it is not what is loading the database.

In our view the fix usually starts at the top of that list: add an index, ask for less data, or move a heavy report off the database your customers use.

Busy days cause trouble

A system that is fine on a quiet Tuesday but struggles during a sale is showing you its limit. Two things to check, in this order:

1. How full it gets. Systems often slow down before they reach 100% (the SRE book makes this point). Track the 99th percentile of response time over a short window. A rising number is often an early sign that you are nearing the limit.
2. What your software does when something is slow. Retries add load to a server that may already be struggling, and can keep the load high after the original problem is fixed. An Amazon engineering article on timeouts and retries recommends limiting retries, waiting longer between them, adding randomness so clients don’t all retry at once, and retrying at one layer only.

Retrying at every layer multiplies the load. These numbers are illustrative: if each layer tries up to three times, the number of attempts grows like this as the request moves down the chain.

Retrying at one layer keeps it at three. So a busy-day failure can be a small overload that the retries made worse, which is worth checking before you buy bigger servers. To rehearse a busy day, see our guide to getting your app ready for a traffic spike.

Small changes take weeks

When a simple feature gets a three-week estimate, or every release breaks something unrelated, the code may be tangled. Parts that should be independent depend on each other in ways nobody fully remembers.

Two numbers show it: change lead time and change fail rate, both defined above and both tracked by DORA. Our reading is that tangled code makes both worse. Changes ship slower, and more of them go wrong.

Record both for a quarter. If lead time is long and the fail rate is high, pick the kind of change that hurts most and trace what it touches. If one small change reaches into many modules, that suggests a boundary is in the wrong place.

Everything waits on one component

Many products have one part that everything else leans on: an order job, a partner integration, a PDF service. When it slows down, everything that calls it slows down too.

There are two defences:

• Set a timeout on every call to it, based on measured latency, so one slow part can’t hold up the whole product. The same Amazon article gives this advice.
• Put it behind a queue with its own retries and its own scaling. In our view this takes the most pressure off.

Measure latency and errors for each dependency first, so you know which one it is.

Costs grow faster than users

If your cloud or hosting bill is growing faster than your customer base, it is worth checking whether the system is doing work it doesn’t need to. The way to see it is a unit cost: what you spend per customer, per transaction or per order. The FinOps Foundation’s unit economics page lists examples: “per million authorized users, per transaction, per customer, or per case resolved.” Pick one that fits your product and chart it every month.

• Unit cost is flat: a bigger bill just means you grew.
• Unit cost is climbing: find the largest line item and ask what changed. In our view the usual suspects are servers sized for a peak that happens twice a year, the same result recomputed instead of cached, and data moved around for no reason.

AWS’s cost guidance describes right-sizing as “an iterative process”, triggered by changes in usage. It adds that right-sizing can be a one-off if the effort outweighs the savings over the life of the workload. Cost and speed problems often share causes, so in our view a fix for one tends to help the other.

What to do about it

Put the five measures in place before you change any code. In order:

1. Record a baseline. Collect the table’s measures for four to six weeks, including at least one busy period.
2. Rank the signs by business impact. A slow checkout usually matters more than a slow admin page.
3. Fix the cheapest causes first. Query tuning, caching and moving heavy work into background jobs cost less than restructuring code in our view, and your measures will show quickly whether they worked.
4. Isolate the one component everything waits on, with timeouts and limited retries.
5. Re-architect a specific component only if the numbers show it is the limit. Make it a targeted decision backed by measurements, not a reaction to general frustration with the codebase. For a bigger move, see rewriting or modernizing. For a second opinion on the numbers, our performance and scalability work is the place.

Pick the one sign that costs you most this month, find its measure in the table, and write down today’s number. Check it again in four weeks. If it is moving the wrong way, you have a target for the first fix, and a baseline to prove the fix worked.

Sources

• Google: Site Reliability Engineering, Chapter 6, Monitoring Distributed Systems
• DORA: Software delivery performance metrics, last updated 5 January 2026
• PostgreSQL documentation: pg_stat_statements
• Amazon Builders’ Library: Timeouts, retries and backoff with jitter, 5 December 2019
• Shopify: Store speed and conversion, 27 April 2026
• FinOps Foundation: Unit Economics capability
• AWS Well-Architected Cost Optimization Pillar: Select the correct resource type, size, and number