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.

Test environments rest when nobody uses them

A pre-production or development environment spends a good part of the day, and nearly every night, without anyone opening it. So that no capacity sits reserved and unused, those environments go to rest automatically when nobody uses them and wake up on their own when someone comes back.

State	When	What stops
Light sleep	After 30 minutes without use	The application. The database keeps running.
Deep sleep	After 8 hours without use	The application and the database as well.

What counts as use: browsing the application, calls to its API, and having a tab open with someone active in it. A forgotten tab stops counting when the application itself marks the user as away, after 30 minutes without activity.

How it wakes up:

By opening its address. A "Starting…" page shows the progress and takes you to the application as soon as it answers.
With a click in a tab that was left open. The first click starts the environment; the next ones already work, without reloading the page.
From the management console, with the Wake button.
A deployment or a configuration change is applied even while the environment is at rest: it wakes up to update and goes back to sleep.

How long it takes, measured on the platform:

From	With fast boot	Without fast boot
Light sleep	about 20 seconds	around a minute and a half
Deep sleep	between 40 seconds and a little over a minute	about 2 minutes

Fast boot skips repeating the application's preparation when nothing has changed since the last time. It reaches each environment with its next build, without you having to ask for it.

What rest does not touch

Production environments never go to rest, and neither do on-premise environments. Rest stops processes, not data: it deletes, moves and restores nothing, and on waking up the environment is exactly as you left it. If a test environment must always be available — an integration that calls it at fixed times, a demo — it can be excluded: see Compatibility and limits.

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.