Growth Projections

Back to Server Setup · Workload Requirements · Infrastructure Audit · Service Offerings

Growth projections establish where the business expects to be in 12–24 months, so the setup does not need a redesign after the first growth spurt. It is the third stage of a server setup, and it is the one that decides whether the sizing produced by workload requirements has a useful lifetime or an accidental one.

The purpose is not to predict the future accurately, which nobody can do. It is to establish what breaks first, at what multiple of today's load, and to agree the point at which somebody acts. A projection that turns out wrong but came with a trigger is still useful. A precise forecast with no trigger attached is not.

1. Growth Is Several Different Numbers

“We expect to double” is not a requirement, because the things that grow do not grow together and do not stress the same components.

• Users — usually the slowest of the four, and the one the business actually forecasts.
• Transactions — can grow faster than users if each user does more, and this is what drives CPU and database load.
• Data — the important one, because it is monotonic. Traffic falls back after a peak; stored data does not. Even a business with flat revenue accumulates data, which is why storage and backup windows are so often the first thing to run out.
• The estate itself — more services, more environments, more integrations. This grows with the engineering team, and it consumes operational capacity rather than CPU.

Each of these needs its own rate. Where history exists, measure it — the last twelve months of actuals is a far better forecast than anyone's expectation, and the infrastructure audit usually supplies it.

2. The Arithmetic People Get Wrong

Growth quoted per month compounds, and the intuition for compounding is poor. 5% a month feels modest and is not:

Two consequences. A system sized with 2× headroom and growing at 8% a month has spent it within a year. And the second year is always the expensive one — at 8%, year two adds more absolute load than year one did, which is why a plan that looked comfortable at the 12-month mark can be in trouble by month 18.

3. Find the Shortest Bar

An estate does not run out of capacity as a whole. One component runs out first, and everything else is irrelevant until that one is dealt with.

The components that run out first are consistently the ones nobody thinks of as capacity:

• The backup window. Data grows; the overnight window does not. A backup that takes four hours today takes nine at 2× data, and the window is six. This is arithmetic, and it arrives on a predictable date.
• Connection and pool limits — a ceiling in configuration rather than in hardware, and one that fails abruptly rather than gradually.
• A single writer. Reads scale out easily; writes to one primary do not. Where that limit sits should be a known number, not a discovery.
• Anything that scans everything. A nightly job over the whole table grows with total data rather than with new data, so its runtime grows even when nothing else does.
• Operations. One administrator can look after a certain number of systems. That ceiling is real and is reached quietly — see infrastructure as code, which is largely how it is raised.

4. Two Numbers, Not One

A good plan distinguishes what the setup is sized for from what it can reach without being rebuilt:

• Sized for — the load it comfortably carries today, with peak load left of the utilisation bend. Typically 12–24 months of expected growth, no more, because capacity bought for year three is paid for now and may never be used.
• Extends to — how far the same design goes with money but no redesign: bigger instances, more disk, another replica. This is the number that prevents the redesign-after-the-first-spurt problem, and it costs nothing to establish at design time.

Where the two differ is the architectural decision. Scaling up has a hard ceiling — the largest machine available — and is simple until you hit it. Scaling out has no such ceiling but requires the application to tolerate it, which is a property of the software rather than the infrastructure and cannot be added at the moment it is needed. Deciding which at design time is cheap; discovering it under load is not, and this is where design work connects to architecture design and high availability.

5. Triggers, Not Dates

The deliverable is a short list of trigger points, each in the form “when X crosses Y, do Z, and Z takes W weeks”. For example: when the database exceeds 400 GB, order the larger volume; lead time three weeks. When peak CPU exceeds 65% on three consecutive weekdays, begin the move to the larger instance.

This works when a forecast does not, for three reasons. It fires on what is actually happening rather than what was predicted. It includes the lead time, so the action starts early enough — and hardware lead times in particular are measured in weeks. And it names the action, so nobody has to decide what to do while the system is already struggling. Triggers are only useful if something watches them, which is the point at which this becomes a monitoring requirement rather than a planning one.

6. Growth Is Not Always Upward

Worth stating plainly, because plans rarely account for it. Businesses shrink, seasonal businesses spend most of the year below peak, and a project can end. Infrastructure that can only grow is a liability in those cases: owned hardware cannot be handed back, and a three-year commitment cannot be cancelled. Where the direction is genuinely uncertain, the ability to scale down has real value and belongs in the comparison — which is one of the inputs to budget and constraints.

What You Get

• Measured growth rates for users, transactions, data and estate size — from your own history where it exists, and stated as an assumption where it does not.
• A headroom figure per component: the multiple of today's load at which each becomes the limit, shortest first.
• Two sizing numbers — what the setup is sized for, and how far it extends without a redesign.
• A trigger list: metric, threshold, action, and lead time.
• The point at which the current architecture stops being the right one, so that decision is scheduled rather than forced.