Challenge 3: Connect to a Prior Site Gotcha — Possible Solution
====================================================================

SIMILAR GOTCHA: mongodb2-6's Challenge 3 ("Shard or Not?") from the
MongoDB course, which addresses a company with a 50,000-document
product catalog that "comfortably runs on a single 3-node replica set
with room to spare," asking whether they should shard it now "in
anticipation of future growth." The chapter's own answer is a firm no
— sharding preemptively adds real operational complexity (choosing a
shard key you're stuck with, deploying mongos routers and config
servers) for a scaling need that doesn't currently exist, purely
speculative future growth that may or may not ever materialize.

THE SHARED UNDERLYING PRINCIPLE: both gotchas warn against adopting a
distributed-systems technology's full complexity BEFORE there's a
real, demonstrated need for what that complexity buys — sharding
solves a genuine "too much data/write load for one node" problem, and
orchestration (Kubernetes/Swarm) solves a genuine "need automatic
scheduling/self-healing across many machines" problem, but both come
with substantial ongoing operational cost that isn't worth paying
until the specific problem they solve actually exists. In both cases,
the "it might help someday" justification isn't sufficient on its own
— the correct default is staying with the simpler tool (an unsharded
replica set; Compose) until growth genuinely, concretely outgrows it,
not preemptively adopting complexity in anticipation of a need that
may never materialize.