Scaling and capacity

Your operation doesn't put the same load on the system every day. A month-end close, a campaign, a bulk import or an integration firing thousands of operations in a row demand something from your environment that an ordinary Tuesday does not. This page explains how your environment is sized and what we do when load grows.

Two ways to grow

More instances (horizontal scaling): additional copies of your application serving requests in parallel, with traffic spread across them.
More resources per instance (vertical scaling): more compute capacity and more memory for the same component.

Both are applied to your existing environment, without rebuilding it and without migrating you anywhere else, following the same controlled procedure as any other change (see Deployments and changes).

Deployment models

Not all workloads are alike, and much of the difference between absorbing a peak and feeling it lies here. Your environment can run in two ways:

Model	How it runs	What for
Unified	A single set both serves user requests and runs background processes.	The general case: simple and sufficient for most operations.
Split	User requests, scheduled tasks and background processes run in independent sets, each with its own resources.	High transaction volumes, heavy processes or intensive integrations.

The advantage of the split model is direct: a bulk invoicing run, an import or a recalculation does not compete for the resources serving the people using the application at that moment. The heavy process takes as long as it takes; the application keeps responding.

flowchart LR
    U([Users]) --> W["User requests<br/>one or several instances"]
    T["Scheduled tasks"] --> DB
    F["Background processes<br/>and integrations"] --> DB
    W --> DB[("Database<br/>+ connection pooler")]

The database

It is the piece that feels a high transaction volume first, which is why it has two mechanisms of its own:

Replica and automatic failover: the database can be deployed with a synchronized secondary copy. If the primary instance fails, the replica takes over automatically, with no manual intervention and without restoring a backup.
Connection pooler: between your application and the database sits a piece that reuses and multiplexes connections. That is what keeps many simultaneous users and processes from exhausting the database's connection capacity.

The entry gateway grows on its own

The gateway through which all HTTPS traffic enters automatically adjusts its number of instances according to the traffic it receives: it grows when traffic rises and scales back when it falls. This is the piece where automatic growth makes sense, because its work is uniform and does not depend on your business logic.

In front of your application there are also reasonable request limits, so that anomalous traffic — automated or accidental — does not degrade the service. They are adjustable: if your integration needs a higher throughput, it is coordinated and raised.

Capacity levels

When aggregate demand on the platform tightens, not all environments are equal. Each environment has a capacity level:

Level	What it means
Critical	Resources reserved exclusively for the environment, always available whether it uses them or not. For operations that cannot tolerate degradation. Enabled on request.
Production	Priority over pre-production and development: when room is needed, they give it up. This is the level of every productive environment.
Pre-production	Below production; never displaces another environment.
Development	The lowest level; never displaces another environment.

What it is and what it isn't

A capacity level orders who gets room first when demand tightens. The critical level goes one step further and reserves that room in advance. Neither one is, on its own, a performance commitment: that comes from how your environment is sized and, where applicable, from your service contract.

How it is decided

Neither by eye nor by incident:

We measure. Continuous monitoring of compute, memory and storage usage, and of response times (see Monitoring).
It gets proposed. By us, when the trend calls for it; or by you, when you know a foreseeable peak is coming: a campaign, a migration, a period close.
It gets applied like any other change: described in versioned configuration, reviewed and rolled out through progressive replacement, with no perceptible cutover and reversible.

On request, and on our recommendation

Additional instances, the split deployment model, a database replica and the critical level are available capabilities, not automatic ones: we enable them when you ask us to, and we recommend them when what we measure calls for it. In both cases the change is applied to your current environment.

What this does not cover

Scaling answers more load. For the failure of a single piece there is high availability, and for a serious scenario, disaster recovery. Three answers to three different problems, and worth not confusing.