[Spike] Benchmark score-cache freshness and invalidation strategies

[knytcomics-ui]

Category

Spike

Question

How should score caching balance latency, oracle freshness, privacy, and correctness once scores come from a live service?

Context

The adapter has a process-local LRU cache with a three-minute TTL, designed around a deterministic stub rather than changing external risk data.

Why This Matters

Long TTLs can show stale risk; short TTLs increase latency, cost, and privacy exposure.

Areas to Investigate

• TTL by score/provenance class.
• Network-aware keys.
• MV3 worker lifecycle.
• Persistent versus memory storage.
• Invalidation and negative-result caching.
• Concurrent request coalescing.

Evaluation Criteria

Freshness, latency, memory, privacy, oracle load, complexity, and failure behavior.

Expected Deliverables

Representative benchmarks, architecture comparison, recommended key/TTL rules, and invalidation design.

Acceptance Criteria

• Current cache behavior is measured.
• At least two cache architectures are compared.
• Stale and failed-score behavior is defined.
• Concurrent identical requests are evaluated.
• Recommended policy and implementation scope are recorded.

Follow-Up Opportunities

Live adapter cache, request coalescing, freshness display, and cache metrics.

Cross-Repository Impact

Potential impact on oracle response metadata and cache headers.

Complexity

Spike

Impact

High — affects correctness and production scalability.

Suggested Labels

spike, performance, architecture