Working AtlasProbabilistic structures

Heavy-Hitter Sketch

Use a small counter table to estimate which event types are most common.

TrySet Width w to 4, start the stream, then compare an estimate with the true count.

Watch forCollisions can raise an estimate above the true count; the seeded stream is synthetic.

Jump to the model

Independent systems exercise

Standalone teaching model; it represents no production implementation.

Interactive model

Ready when you are

The sketch is empty and waiting. Start the stream when you are ready to watch counters fill and collisions appear.

Sketch shape

Width w (columns)64 cols

Depth is fixed at 4 independent hash rows. Narrower width means more collisions per column and more overestimation; widening it rebuilds the sketch fresh.

Firehose

Event rate12 events/sec

Events processed

Distinct keys

Extra counts

Estimated counts above the exact counts, summed across all keys.

Grid size

4×64

depth × width

Leaderboard

Top estimated heavy hitters

Waiting for events to stream in…

Counter heat (higher = hotter)
Selected key — cell hit this row
Row giving the MIN (the estimate)

Seed1

Query

Estimate a key

Key to inspect

Pick a key to highlight its cell in every row and see which row produces the minimum (the sketch's reported estimate).

Preparing the interactive experiment…

Skill practicedFind frequent event types with limited memory

Transferable practiceA small counter table saves memory, but shared counters can make an event look more common than it is.

Understand the result

A cumulative Count-Min Sketch estimates key counts using a compact counter table. This demo has no sliding window or counter decay. Positive updates can inflate estimates through collisions; it does not claim the formal probabilistic error bound because it does not implement its standard randomized hash assumptions.

Controls

Width w (columns): How many counters each hash row has. A narrow table tends to create more collisions; compare the observed estimates and memory use when you change the width.
Event rate: How many events enter the sketch per second. The same rate is used regardless of the screen refresh rate.
Start stream: Starts the stream. While it runs, this button reads “Pause stream”; after pausing, it reads “Resume stream” and keeps the accumulated counts.
Reseed: Clears the counters and generates a new seeded event sequence and hash mapping. The current width, speed, and paused state are preserved.
Step model: When reduced motion is enabled, advances the simulation in four paced frames at the selected event rate while automatic animation stays paused.

What to watch for

With positive-only updates, collisions can add counts but cannot subtract them. Compare estimate with exact count; the formal error bound also depends on hash assumptions and table dimensions.
Change Width w and inspect the counter table and total overestimation; a particular key's estimate can move differently as the seeded hash mapping changes.
The same seeded event stream can be compared at different widths, but a wider table does not guarantee every observed estimate will fall.
Open the collision autopsy to see which other generated keys share the selected key's counter in this seeded run.

Why it happens

Each positive update hashes a key into one counter in every row. A collision can inflate a counter, and the minimum across rows gives this implementation its one-sided estimate: it cannot fall below the exact count under positive-only updates. Wider tables often reduce collision pressure, but the particular estimates here depend on the seeded hash mapping; this simulation does not claim the formal probabilistic error bound or model a production workload.

What this exercise helps me practice

This standalone data-structures exploration is not a product implementation. It shows how I evaluate probabilistic approximations under a memory budget and why observed estimates, collision patterns, and formal-error assumptions must be kept distinct.

See the broader engineering brief