Patterns

Scale up first

Give the App Server a bigger instance before you add a second one. It is the cheapest change that adds capacity.

Resize the App Server to the next instance size before you reach for a second machine.

Move up when#

  • The App Server's CPU bar is full while the Database has room.

  • p99 climbs and some requests are dropped, though no one component is broken.

The Design#

Drag to pan. Hold Ctrl or Cmd and scroll to zoom.

At 3.00k Users the Simulation solves this Design to Apdex 0.34, p99 5.1 s, 22.6% errors and $0.60/s Burn.
WhereSettingValueWhy
App ServerInstance sizemicroMicro is the starter size. Its CPU is the first thing to fill as Users arrive.
DatabaseInstance sizesmallThe Database has room to spare, so the App Server is the only limit.

Drag to pan. Hold Ctrl or Cmd and scroll to zoom.

At 3.00k Users the Simulation solves this Design to Apdex 0.99, p99 332 ms, 0.0% errors and $0.80/s Burn.
WhereSettingValueWhy
App ServerInstance sizesmallOne step up gives the App Server twice the vCPUs for a small rise in Burn. Resizing restarts the Node, so do it before the peak.
DatabaseInstance sizesmallUnchanged, so the App Server is the only difference.

Same Users, same Database. The only change is one size step on the App Server.

Why it works#

A size step doubles the vCPUs and costs a little more Burn. Nothing else changes: no balancer, no second copy, no question about shared state. In the second picture the App Server's load bar drops well under full, the dropped requests stop, and p99 falls back to normal.

Scaling up is also reversible. If the peak was short, resize down and the bill follows.

What it costs#

A resize restarts the Node and it comes back cold, so do it before the peak and not during. Sizes top out, and one box is still one failure. Price rises with size, so you pay for capacity you use only at the peak.

A runtime that runs one process cannot use extra cores. Plain Node.js is one event loop, so doubling its vCPUs buys little, and a second copy or a cluster runtime helps more. Check the runtime before you pay for cores.

In Quorum#

Resize from the Node's Inspector, and read the cost before you commit. Find the bottleneck shows how to tell the App Server from the Database. The glossary defines vertical and horizontal scaling. The next rung is several App Servers behind a Load Balancer.