Inkwell is launching, and the launch brings a crowd.

Workload

Normal traffic is 1 500 rps, but from 5 s to 15 s a launch spike hits 6 000 rps. Still 80% reads / 20% writes against 1 000 notes, for 20 seconds in total.

Why the starter design falls over

An app server on the medium tier with 2 replicas handles about 2 700 rps. Past that, requests wait in a queue; when the queue is full, the rest are turned away as errors.

Two ways to add capacity

• Scale up (vertical): pick a bigger instance tier (S, M, L, XL) so each replica gets more CPU.
• Scale out (horizontal): add replicas. A load balancer in front decides which replica gets each request.

Both are fine here. Real systems usually scale out, because one machine can only get so big.

Tiers

• Easy: the app tier keeps up. Fewer than 15% of requests fail during the launch. Put a load balancer in front and give the app tier room for 6 000 rps.
• Medium: nobody is turned away. Once the app tier keeps up, something else becomes the bottleneck. Find it and fix it too.

Hints

• After a run, click a component and open Metrics. The Saturation bars show which limit filled up: threads, queue, CPU or database connections. Red means full.
• Select a component to change its tier and replica count right on the canvas.