# Exercise 2: Diagnose a Read Hotspot on a Well-Sharded Cluster

## Scenario

`ClipCast`, a short-video platform, shards its `videos` and `video_stats` (view counts, likes) tables by `hash(video_id) % 16`, across 16 shards. Storage is close to perfectly even across all 16 shards — the platform's monitoring confirms each shard holds between 6.1% and 6.4% of total video rows, well within expected variance for hash sharding.

On Tuesday, a video uploaded by a mid-sized creator unexpectedly goes viral (picked up by a large external platform's algorithm) and receives 40 million views over 6 hours — roughly triple the platform's *entire normal daily view-count-increment volume* concentrated onto this one video's row.

Incident symptoms:
- Shard 11 (the shard `hash(that_video_id) % 16` maps to) shows CPU pinned at 100% and write latency climbing into the seconds for the entire 6-hour window.
- Shards 0-10 and 12-15 show completely normal load the whole time.
- The specific slow operation, per the query log, is `UPDATE video_stats SET view_count = view_count + 1 WHERE video_id = ?` — a single-row read-modify-write, executed roughly 1,800 times per second, all against the exact same row, for 6 hours straight.

## Deliverables

1. **Name the failure mode** using theory (Part 2) section 4's terminology, and explicitly explain why this is happening despite storage being nearly perfectly balanced across shards — what does "balanced" measure that turned out not to be the actual bottleneck?
2. **Explain why re-sharding with a different hash function would NOT fix this**, using theory (Part 2) section 4's point about this problem not being about the key's distribution — walk through what would happen to the viral video's row under a different hash assignment.
3. **Propose a concrete mitigation for the write-side hotspot specifically** — the incident is dominated by 1,800 writes/sec hammering one row, not reads; theory (Part 2) section 4 discusses a caching-layer mitigation for read-side celebrity problems and briefly mentions sub-sharding a hot key's own data for write-side problems — describe what sub-sharding `view_count` for this one video concretely would look like (hint: consider whether every increment needs to update the exact same row synchronously, or whether the count could be split and reconciled).
4. **State one thing your mitigation trades away** — every fix has a cost; identify what becomes harder, slower, or less precise as a result of your proposed change (e.g. read consistency, implementation complexity, when the "true" total count is knowable).