Challenge 3: Shard or Not? — Possible Solution
====================================================================

NO, they should not shard yet.

The chapter's decision criteria are specifically about a single replica
set genuinely being unable to hold the working data set or keep up
with write throughput. 50,000 documents "comfortably" fitting on a
3-node replica set "with room to spare" is the direct opposite of that
signal — there is no current problem sharding would solve.

Sharding preemptively has real, immediate costs with no corresponding
benefit yet:

  - A shard key has to be chosen now, while the query patterns that
    should inform that choice may still be unclear or may change as
    the product evolves — and changing it later (resharding) is heavy.
  - The operational surface area grows immediately: mongos routers and
    config servers need to be deployed and maintained, on top of the
    replica set(s) that already exist.
  - None of this buys any actual capacity the application needs today.

The better path: keep the single replica set, continue applying this
course's earlier chapters (indexing, schema design, the aggregation
framework) as the real workload grows, and revisit sharding later IF
and when the data size or write throughput genuinely approaches what
one well-resourced replica set can handle — the same "don't solve a
problem you don't have yet" principle that applies to premature
optimization generally.