A single VM that polls Meraki sites and transforms JSON for a water-utility dashboard is CPU-saturated. The workers are designed to be identical and stateless behind a load balancer. Which scaling direction matches that constraint?
Select an answer to reveal the explanation.
Short Explanation
When one kitchen is slammed, hiring more cooks who share the same recipe beats buying one giant stove that still has one pair of hands. Stateless Cisco-API workers scale horizontally behind the balancer. A bigger single VM hits a ceiling.
Full Explanation
Identical, stateless workers behind a load balancer are built for horizontal scale-out. When a single VM polling Meraki sites and transforming JSON saturates CPU for a water-utility dashboard, the matching move is to add more interchangeable workers and distribute load—not to bet everything on enlarging one host. Statelessness means any worker can poll or transform the next batch without local sticky state.
Replacing the fleet with one oversized bare-metal host fails because vertical scale still hits a ceiling and removes the balancer's ability to absorb instance loss. Moving the poller into each clerk's browser fails because it shifts privileged Meraki work to untrusted clients, multiplies quota use, and cannot coordinate a shared poll schedule. Pinning all polling to one thread and only raising memory fails because CPU saturation needs concurrency and more workers, not a larger heap on a single bottleneck process.
Exam caveat: scale-out assumes no conflicting local mutable state; if workers write the same local file or hold unique in-memory sessions, fix that before adding copies.
Operational check: add a second identical worker, confirm Meraki poll throughput rises and per-instance CPU drops, and verify no duplicate-destructive side effects from concurrent pollers.