Exercise 3: The Specific Conditions Horizontal Scaling Actually Needs — Possible Solution
====================================================================

CONDITION 1, FROM THE ALGORITHMIC-BOTTLENECK FINDING
------------------------------
This chapter verified a linear duplicate-check growing from 104x to
1,785x slower than an O(1) equivalent as data size grew - and
explicitly verified that neither vertical NOR horizontal scaling fixes
this on its own, UNLESS the underlying data itself gets split up in a
way that shrinks what each machine has to scan (which is a real,
separate architectural decision - Chapter 4's own database sharding,
not something "adding servers" does automatically). The specific
condition: horizontal scaling only helps a bottleneck like this if the
work can genuinely be partitioned so each machine handles a smaller
slice of the SAME O(n) problem - simply running identical copies of
the slow check on more machines just means more machines are each
independently slow.

CONDITION 2, FROM THE MULTIPROCESSING FINDINGS
------------------------------
This chapter verified a small workload (8 calculations) got MEASURABLY
SLOWER when parallelized (0.33x-0.37x "speedup," i.e. ~3x worse),
while a large workload (160 calculations) got genuinely faster, but
only once there was enough actual work to amortize the real overhead
of spawning and coordinating separate processes. The specific
condition: horizontal scaling only helps when the total useful work
per unit is large enough that the coordination overhead (spawning
processes, sending data, collecting results) is small relative to it -
below that threshold, adding parallelism is a net loss, not a smaller
gain.

WHY "JUST ADD MORE SERVERS" FAILS BOTH CONDITIONS BY DEFAULT
------------------------------
Neither condition is guaranteed just by having more hardware available.
Condition 1 requires a genuine architectural decision about how data is
split, which this chapter deliberately didn't solve (it's Chapter 4's
own topic). Condition 2 requires the workload itself to already be
large and genuinely parallelizable - properties of the WORK, not of how
many servers exist to run it on. A team that scales horizontally
without checking either condition first risks reproducing this
chapter's own two findings exactly: paying for extra infrastructure
that either doesn't touch the real bottleneck at all, or actively makes
a small, fast operation slower than leaving it alone.

WHY THIS WORKS AS AN ANSWER
------------------------------
Each condition is stated precisely, in terms of this chapter's own two
verified findings, rather than as a general truism about scaling, and
the explanation connects both conditions back to why "add more servers"
is a default that can fail in two structurally different ways, not
just one.