Name the target

"It needs to scale" is not a requirement. Ten thousand users, a thousand requests per second, and a terabyte of new data per month are requirements, and each implies different architecture.

Ask where the number came from. Targets derived from a sales forecast are frequently an order of magnitude above what arrives, and designing for them costs real money now against revenue that may not appear.

Distinguish reversible from structural

Adding servers, caching, and tuning queries are all things you can do later, cheaply, when you have evidence. There is no advantage in doing them early.

Data model, tenancy, identifier strategy, and whether your service can run as more than one instance are structural. Getting these wrong is expensive to fix and they are worth deciding carefully even at low volume.

Design so it can scale, do not scale it yet

Statelessness, a schema that will partition if it has to, and background work already separated from request handling cost almost nothing to establish at the start.

That is different from actually distributing anything. Keep the door open and walk through it when the traffic arrives.

Most scale pain is in the data

Application servers are easy to add. Databases are not, and the problems arrive earlier than most teams expect — a query that was fine at ten thousand rows behaves very differently at ten million.

Index deliberately, watch query plans as data grows, and know in advance which table will become the problem first.

Measure before you optimise

Intuition about bottlenecks is reliably wrong. Load test against realistic data volumes and find the actual limit rather than the one you expect.

Test with production-shaped data specifically. Synthetic data is usually uniform, and real data is skewed in ways that break exactly the assumptions that looked safe.

Watch the leading indicators

Track the metrics that move before failure — query duration at percentile, queue depth, connection pool saturation — so capacity work is scheduled rather than triggered by an outage.

Knowing you are six months from a limit is a planning problem. Discovering it on a Friday afternoon is not.

Written by the Global IT Solutions engineering team. Working through this decision right now?

Start a conversation