What's built on it
Every consumer here builds on the same fused signal — count, recency, and first-sighting from one Sketch.Observe() call — aimed at a different question. What's below is what exists today, not a closed list; new tracks land here as they're built.
Sketch instance (SketchProxy allocates several, one per feature) — nothing here reads another consumer's counters, and none of them coordinate across processes, same as the core library's own "one process, one table" non-goal.A production-shaped consumer: rate limiting, wallet defense, prompt caching, and an agentic-loop breaker, all gated by independent Sketch instances in front of httputil.ReverseProxy. The most complete of the three tracks — it has its own CLI, Docker image, and release pipeline.
Does fusing frequency + first-sighting into one structure eliminate the second structure (a Bloom-filter "doorkeeper") every TinyLFU-family cache needs? Benchmarked against go-tinylfu and plain LRU on synthetic Zipfian traffic, a real Twitter CDN trace excerpt, and the standard scan-pollution test.
| Test | Result |
|---|---|
| Hit rate, 1% cache size | 64.6% (epochsketch) vs. 63.1% (go-tinylfu) vs. 53.0% (plain LRU) |
| Scan pollution (top-20 survival) | 20/20 survived vs. 0/20 for plain LRU |
| Memory, ~65,536 entries | ~21% less heap than go-tinylfu's two-structure design |
EpochSketch explicitly rules out cross-process coordination — "one process, one table." A real telemetry deployment is never one process: it's N independent collector instances. This simulates that fleet shape directly against a stateless hash-threshold baseline before any real OTel processor gets built on top of it. Finding so far: routing policy, not the sketch itself, determines whether rare templates actually get protected across an uncoordinated fleet.