Hashtag counters

Business constraint

Trending tags need counts. One celebrity tag can dominate write QPS.

Naive v0

UPDATE counters SET count=count+1 WHERE tag=? on one row. Or exact COUNT(*) on events.

Failure drill

Hot row lock contention. Single Redis key CPU pegged. Exact counts too slow for feed paths.

Evolution path

Iteration 1

Shard counter keys (tag+bucket). Aggregate on read. Accept brief inconsistency.

Iteration 2

Approximate structures (sketches / probabilistic) where exactness is not contractual.

Iteration 3

For exact-enough dashboards, async aggregator from append-only events.

Implementation cut

Decide exact vs approximate as a product contract. Document error bounds. Apply hot-key tactics before buying bigger boxes.

Numbers

Write QPS per physical key after sharding. Relative error bound for approximates. Read p95 for trend UI.

Pattern tags

• approximate-counters
• hot-key-tactics

Self-check

1. Why is one counter row dangerous?
2. How does key sharding help?
3. When is approximate OK?
4. What is a hot-key tactic beyond sharding?
5. How do async aggregators change freshness?

Walkthrough

Recordings will appear here when published. Until then, work the failure drill and lab locally — pause after each iteration and write the metric that moved.