A big events table is sharded across 5 shared-nothing nodes.
Run a query and watch the coordinator fan it out to every shard at once — each scans
only its own slice in parallel — then merge the partial answers into one.
Compare it with running the same work on a single machine.
What you're seeing: the coordinator sends the same query to all 5 shards
simultaneously (fan-out), each shard scans its own rows in parallel, and the coordinator sums the
partial counts (fan-in / merge). Five shards scanning at once finish in about the time of the
slowest single shard — not the sum of all five. That's the parallel win.
Try the range(region) shard key: now most rows pile onto one shard. That shard becomes
the hot shard — it does almost all the scanning while the others idle, and your speedup
collapses. Same query, different shard key, wildly different performance. Choosing the shard key is one of
the highest-stakes decisions in database design: it's load balancing (Session 09) wearing a
database costume.
The gotcha: COUNT, SUM, MIN, MAX merge trivially
because they're reductions. But you can't average per-shard averages — each shard must return
its SUM and COUNT so the coordinator can divide at the very end.