Missing caching on hot reads
Part of the Scalability antipatterns check · fix arrives as a guide
What it is
A read that runs on nearly every request returns data that changes rarely, with no caching layer in front of it.
Why it matters
You pay full query cost for an answer that was the same a second ago. It is the cheapest performance and cost win available, and its absence usually shows up first as database load rather than as user-visible latency.
How to fix it
Cache the result with a short TTL, keyed by whatever varies. Start with a time-based expiry — it is far simpler to reason about than explicit invalidation, and for data that changes rarely the staleness window is not noticeable.
Run them all on your app
Connect your repo and your live services with read-only scopes. The first scan is free, and nothing changes without your approval.