# How automatic scaling decides to add an instance

A look at the signals behind scaling decisions—request rate, saturation, latency, and queue depth.

Published: 2026-07-14
Author: Darwa Engineering
Category: Engineering
Tags: autoscaling, performance, observability, infrastructure

## Scaling is a decision, not a threshold

Adding an instance because CPU briefly crossed a line creates unstable systems and unpredictable bills. Darwa treats scaling as a decision based on sustained demand, available capacity, and the type of work a service performs.

For web services, the control plane watches request rate, concurrency, response latency, CPU saturation, and memory pressure. A single spike is not enough. The signal must remain outside the service's healthy operating range long enough to justify another instance.

## Different workloads need different signals

A background worker is usually limited by queued work rather than HTTP latency. Darwa combines queue depth with completion rate to estimate how long the current workers will need to clear the backlog. If that drain time exceeds the target, it adds capacity within the minimum and maximum limits you selected.

Web services use a different model. Rising concurrency matters when latency also moves away from its baseline. CPU is supporting evidence, not the whole decision. This prevents an efficient, CPU-intensive request from causing unnecessary scaling while still reacting when users begin to wait.

## Safe scale-out and scale-in

New instances must pass health checks before receiving traffic. The deployment remains visible throughout boot, readiness, and load-balancer registration. If an instance cannot become ready, it is replaced without reducing the healthy capacity already serving users.

Scale-in is deliberately slower. Darwa waits for demand to remain below the target, drains active connections, and never moves below the configured minimum. The dashboard shows the signal that triggered each change and its estimated cost, so automatic scaling remains explainable rather than mysterious.

The result is capacity that follows real demand without turning every short-lived spike into permanent infrastructure.