Challenge 2: Explain Query Isolation — Possible Solution
====================================================================

A query that filters by tenant_id — e.g. find({ tenant_id: "T55" }) —
gives mongos everything it needs to know exactly which shard holds
that data, because tenant_id IS the shard key: the config servers'
metadata directly maps shard key ranges/hashes to specific shards.
mongos routes the query straight to that ONE shard, which only has to
search its own (much smaller) slice of the data. This is a targeted
query.

A query that omits tenant_id — e.g. find({ status: "active" }) — gives
mongos no information about which shard(s) might hold matching
documents, because status isn't the shard key and could appear on
documents belonging to any tenant, spread across every shard. mongos
has no choice but to send the query to EVERY shard in the cluster and
merge all their results together — a scatter-gather query. Every shard
has to do its own search work, and the overall query is only as fast
as the SLOWEST shard's contribution, plus the cost of merging results
from all of them.

The practical takeaway for this multi-tenant design: any query path
that doesn't include tenant_id in its filter silently becomes far more
expensive as more shards are added, since scatter-gather queries get
proportionally more expensive (not less) as the cluster grows.