perf: Retire the StatsServer / ETS stats cache

#18 · open · 0 comments

View on GitHub ↗

InterferencePattern

## What to build Benchmarking (#9) confirmed the downloaded/size/home counts are index-only and sub-millisecond warm, so the ETS stats cache is dead weight for them. Decision (#9): **serve all counts live, no cache retained** — including the pending count, once #20 makes it cheap enough. Remove the cache entirely: - `Pinchflat.Cache` and `Pinchflat.Cache.StatsServer` - The supervision-tree entry and the boot warm-up task - The `stats:source` broadcasts threaded through `media.ex` (and the `broadcast_stats_change` helper) - The cold-cache fallback branches in the Sources index and media-item table LiveViews Counts come straight from the now-indexed queries (Sources index via the single GROUP BY from #10; pending via the covering index from #20). Note: `settings.ex` also uses `Cache.get(:settings_record, ...)` — decide whether to keep a minimal cache for the settings singleton or fold it in; it is a different, simpler concern than the stats cache. ## Acceptance criteria - [ ] `StatsServer` and the stats ETS table are gone; app boots without them - [ ] Sources index, source detail, and media-item table show correct counts sourced from live queries - [ ] No `stats:source` broadcasts remain in `media.ex` - [ ] Pending count is served live with acceptable latency (depends on #20) - [ ] Settings-record caching is either retained intentionally or removed with justification - [ ] Cache-specific tests removed; remaining tests pass ## Blocked by - #10 (Sources index must already use the single GROUP BY) - #20 (pending/total counts must be cheap enough to serve live) (#9 benchmark gate — resolved: GO.)

Comments