sharded-counterslisted

# Sharded counters Count a thing that is incremented far faster than a single row, key, or partition can serialize writes — likes, views, votes, rate tallies, inventory decrements. The trap is the **hot counter**: every writer contends on one record, so latency climbs and throughput plateaus no matter how big the box is. Getting it wrong turns a trivial `+1` into the bottleneck of the whole feature. ## When to reach for this Concurrent increments to a single logical count exceed what one row/key can absorb — a viral post's like count, a live-event view counter, a global rate tally. The symptom is write contention (lock waits, CAS retries, partition hot-spotting) on one record while the rest of the store is idle. Reaching for this means the *write* side is the problem, and an exact-to-the-millisecond total is not required. ## When NOT to Low write rate (a single atomic `INCR` handles thousands/sec — don't shard a counter nobody is hammering; YAGNI). Counts that must be transactionally exact and read-after-write consistent at every instant (bank balances, seat inventory at sell-out) — that's a transactional decrement, see `consistency-coordination`, not a fan-out tally. Counting *distinct* items exactly (unique visitors) where you also need the member list — that's a set in the store, not a counter. If reads dominate and writes are cheap, you need a cached aggregate, not sharding. ## Clarify first - **Write rate to the hottest single count** — peak increments/sec on *one*