backend-caching-and-performancelisted

# Backend caching & performance The backend analog of `core-web-vitals-for-ui`: latency and throughput are build constraints, not a post-launch tuning pass. Measure before you touch anything — a guessed optimization that isn't the actual bottleneck is wasted work and new complexity for no gain. ## 1. Measure before optimizing - **Profile, don't guess.** Use the language/runtime's profiler, DB `EXPLAIN ANALYZE` (`database-schema-and-migrations` §3), or request tracing (`observability-logging-metrics-tracing` §4) to find the actual hot path before changing code. "This looks slow" is a hypothesis, not a finding — confirm it with a number. - Reproduce the slow case with realistic data volume and concurrency — a query that's fast against 100 local rows can be a seq scan against 10M production rows, and a handler that's fast single-threaded can contend under real concurrent load. - After the fix, re-measure the same way you measured the problem. A fix that "should" help but wasn't re-verified isn't confirmed. ## 2. Cache layers Three layers, cheapest/fastest to most shared, each trading locality for scope: - **In-process** (local memory, e.g. an LRU map): fastest, zero network hop, but not shared across instances — each process has its own copy, and it's lost on restart/deploy. - **Distributed** (Redis/Memcached-class): shared across instances, survives individual process restarts, but adds a network hop and its own failure/latency mode — treat it as a