Challenge 1: Spot the Hotspot — Possible Solution
====================================================================

created_at is monotonically increasing — every new event's timestamp
is later than every event created before it. That means every new
write's shard key value falls at (or near) the very TOP of the entire
key range that currently exists.

Because chunk ranges are contiguous slices of the shard key's value
space, that "newest" end of the range lives on exactly ONE shard at
any given time. Every single new event, no matter how many shards
exist in the cluster, gets written to that same one shard — the other
shards sit almost entirely idle for writes, receiving traffic only
when the balancer eventually splits and migrates a chunk off the
overloaded shard after the fact (reactively, not preventing the
hotspot from happening in the first place).

The result: sharding was added specifically to scale write throughput,
but this particular shard key choice means write throughput is still
effectively bottlenecked by a single shard's capacity — almost the
same ceiling an unsharded replica set already had.

A better choice would hash created_at (or shard on a genuinely
high-cardinality, non-sequential field instead, if range queries by
date aren't actually the dominant access pattern), scrambling new
writes across shards evenly the same way the chapter's customer_id
hashed-key example did.