Why architecture matters here
Counters fail when used for high-QPS single-key metrics or in ways their limitations bite (no TTL, no mixed batches). The architecture matters because the internal read-before-write plus per-shard idempotency shape performance + correctness.
The architecture: every piece explained
The top strip is the mutation flow. Counter mutation — UPDATE ... SET counter = counter + N. Coordinator reads current, adds delta, writes new. Read local + delta: coordinator computes. Replicate new value with a counter shard ID that helps with dedup.
The middle row is guarantees. Counter column — table must be counter-only. Idempotency via shard IDs prevents double-counting on retries. Consistency — quorum preferred. Read repair for eventual convergence.
The lower rows are constraints. Limitations: no LWT + no TTL + can't mix with non-counter batches. Alternative: per-shard counters + roll-up. Ops: schema separation, hot key detection.
End-to-end flow
End-to-end: page view counter increments per event. Coordinator handles read-before-write + replicates with shard ID. Retry safe. Hot key would be a problem; sharding to per-user counters + roll-up periodically avoids it.