Performance: Caching strategy for public pages

[AndreRobitaille]

Summary

The public-facing pages have no visible caching strategy. As data grows, queries for the homepage (worth watching, recent signals, upcoming/recent meetings) and topic pages (appearances, status events, continuity) could become expensive.

Current State

• Solid Cache is configured in the stack but no explicit caching is implemented in controllers or views
• Homepage builds multiple complex queries: active topics with upcoming meetings, topics with recent continuity events, meetings grouped by week
• Topic show page queries appearances, status events, and summaries
• Meeting show page queries documents, topic summaries, and agenda items
• pgvector similarity searches for topic matching could be expensive under load

Proposed Approach

Fragment Caching

• Cache "Worth Watching" and "Recent Signals" cards on homepage (invalidate when topic continuity updates run)
• Cache topic timeline sections on topic show page
• Cache meeting summary sections on meeting show page

Russian Doll Caching

• Meeting cards within week groups (cache key includes meeting.updated_at)
• Topic cards within lifecycle groups (cache key includes topic.updated_at)
• Summary content blocks (cache key includes summary.updated_at)

Query Optimization

• Review N+1 queries with bullet gem or manual inspection
• Add counter caches where appropriate (e.g., topics.appearances_count)
• Consider materialized views for homepage aggregations if query complexity warrants it

pgvector Index Tuning

• Review ivfflat vs hnsw index performance for knowledge chunk similarity search
• Tune lists parameter based on data volume
• Consider approximate nearest neighbor settings

Measurement

Before optimizing:

1. Add request timing to key pages
2. Profile with rack-mini-profiler in development
3. Identify actual bottlenecks before applying caching

Priority

Low until traffic increases — premature optimization isn't warranted, but the strategy should be documented so it can be applied when needed.

[AndreRobitaille]

Status (2026-04-14): no caching implemented yet. Architecture has evolved since filing — homepage now uses a newspaper layout that computes @top_stories, @wire_cards, @wire_rows, @next_up, @headlines, @meeting_refs on every request. Topic and meeting show pages render structured JSON from generation_data directly. Still low priority until measured bottleneck appears. Strategy proposed in the body remains appropriate.