[Perf] Cache qualified_playlists for /v1/playlists/trending

[raymondjacobson]

Summary

Cache the "trending eligible" playlist id set in app memory with a 5-minute TTL. The set is request-independent (same ~6,952 ids for every caller), but the previous implementation recomputed it from scratch on every request.

Why

/v1/playlists/trending shows up as the second-worst signed-in endpoint by p95 (8.4s, p50 1.95s) and the underlying SQL has a 3-5s mean across multiple variants in pg_stat_statements. The dominant cost is the qualified_playlists CTE walking every public playlist × its tracks (~94k playlists, ~5M playlist_tracks rows) to determine which playlists have ≥5 tracks and ≥5 distinct owners. None of those inputs depend on the caller — caller_id, time_range, auth, none of it.

Impact

EXPLAIN ANALYZE on prod read replica:

Path	Time
Cache miss (1× per 5 min, populates cache)	~2.2s
Cache hit (every other request)	36-41 ms (~125× faster)

Local server end-to-end (full GetPlaylists fetch included):

	Before (this branch)	After
First call (cache miss)	3-5s	3.4s
Subsequent calls	3-5s	350-900ms

Caching trade-offs (the bits I want eyes on)

1. TTL: 5 minutes. Trending playlists are by definition popular — privacy/delete flips are rare. Worst case: a playlist becomes private and can be re-surfaced for up to 5 min. Mitigated by the safety net below.

2. Safety net post-filter. After fetching the playlists from GetPlaylists, the handler drops any with is_private=true or is_delete=true. Even if the cache is stale, a now-private playlist can never reach the response.

3. Drop of per-caller access_authorities filter in the qualified-set computation. Only ~0.05% of visible tracks (716 / 1.39M) have access_authorities set, so structural eligibility (≥5 tracks, ≥5 owners) is overwhelmingly the dominant signal. Dropping this filter is what makes the result wallet-independent and cacheable.

4. Cache size. 4 entries max (one per type × possibly time_range if I add that key later). Memory footprint is trivial — at ~7k int32s each, ~30 KB total.

Risk

• The is_private / is_delete safety net catches the only correctness-relevant staleness window. New TestGetTrendingPlaylists_Albums includes a regression case that flips a playlist private, exercises the cache hit path, and asserts it's filtered out of the response.
• All existing trending tests pass unchanged.

Test plan

• go test -count=1 ./api/... (full suite, all green)
• EXPLAIN ANALYZE confirms ~125× speedup on cache hit path
• Local server timing: /v1/playlists/trending 3.4s first, then 350-900ms warm
• Cache safety net regression test

🤖 Generated with Claude Code