Every juggler who runs out of capacity faces the same question: do I add more of what I have, or do I add something different?
More of the same - four balls instead of three - means a faster, tighter version of the same pattern. The same arc, the same catch position, the same fundamental throw, repeated at higher speed with more objects. Vertical scaling.
Something different - a club or a ring alongside the balls - means a new prop with its own weight, its own rotation requirement, its own timing. The pattern is not the same pattern with more. It is a different pattern. Horizontal scaling.
These two choices look similar when described in a planning document. In practice, they are not the same decision and they do not have the same consequences.
Vertical - more of the same
Adding a fourth ball to a three-ball cascade is demanding but knowable. The fundamental throw does not change. The catch position does not change. The rhythm is faster. The coordination is tighter. The skill required is a higher-intensity version of a skill you already have.
Vertical scaling in infrastructure works the same way. More RAM on a server. A larger instance type. A faster CPU. More database connections. The architecture does not change. The deployment does not change. The team does not need to learn new patterns of coordination. The same system runs faster and handles more.
The limit of vertical scaling is physical and financial: there is a maximum machine size. There is a maximum number of balls a single juggler can track without fundamentally changing how they process the pattern. You can push the ceiling, but the ceiling exists. Eventually, more of the same stops being an option.
Horizontal - something different
Clubs and rings do not add to the pattern. They change it.
A club must be thrown with consistent spin, caught with correct timing, and kept rotating at the right rate or it becomes uncatchable. A ring must be kept vertical throughout its flight or it wobbles off-axis. Neither behaves like a ball. Adding either to a balls-only routine requires learning new motor programs, new timing calibrations, new catch positions - while still keeping the existing balls in rhythm.
This is why horizontal scaling is harder than it sounds, even when the architectural arguments for it are clear. Adding more instances, breaking a monolith into services, introducing a message queue between components - these do not extend the existing pattern. They introduce new props with their own physics. Latency between instances becomes a constraint that does not exist on a single machine. Network partitions become a failure mode. State that was trivially shared now requires coordination. Service discovery has to work before anything else can.
The team that assumes adding more instances is just “adding more balls” will find that clubs fall differently than balls do. The pattern breaks in new ways that the team has not practiced.
The team that assumes adding more instances is just “adding more balls” will find that clubs fall differently than balls do.
Same Prop or Different Prop
The triptych makes the difference visible
The image shows three separate panels. Left: a red ball and its arc above an open hand - forgiving, self-correcting, the prop that teaches you how to throw before anything else. Center: a green club with neon trails tracing its rotation path - precise, demanding, held at the correct angle or the catch fails. Right: a blue ring at the top of its arc above a reaching hand - kept vertical, trusted to maintain its orientation across the flight.
Each prop solves a different problem. The ball is your general-purpose compute - handles most workloads, forgiving of small errors. The club is your specialized processing that requires specific handling, cannot be substituted for something more generic. The ring is your long-running loop, the feedback cycle that must never go flat.
The three panels are not interchangeable. You cannot replace the club with another ball and get the same result. You cannot spin the ring and expect it to behave like a ball. Choosing the wrong scaling direction for the problem means paying for props that do not fit the pattern you are running.
Which question to ask first
Before deciding vertical or horizontal, the question is: what is actually saturated?
If a single machine is at its compute or memory limit, and the work is structured so it can all live on one larger machine - vertical is the right answer. Same pattern, more capacity, simpler architecture.
If requests are arriving faster than any single machine can process them, or if different parts of the workload have fundamentally different resource profiles, or if the ceiling of the largest available machine is not enough - horizontal becomes necessary. Not preferred. Necessary. And it comes with the full cost of a different pattern.
The triptych shows what it looks like when all three are available and running. Each prop in the air. Each following its own path, its own physics, its own timing. The juggler has learned all three. That took longer than learning one.
Before adding a new prop, be certain you need what that prop does - and that you have accounted for what learning it requires.
Related: The Pattern Has a Budget - on what happens when scaling exceeds the system’s ability to track itself.