Killing redundant API calls in a live dashboard
The same navigation kept re-fetching data the app already had. The fix was a product decision disguised as a caching one.
The symptom
On Pulse, our engineering-analytics dashboard, moving between a metric and its breakdown felt slow exactly where people used it most. The data had not changed, the view had, and yet the app went back to the network every time.
The root cause
Profiling pointed at the data layer before the components. The query cache was tuned aggressively for freshness: very short staleness windows plus refetch-on-mount meant shared queries re-fetched on almost every navigation, even though the cache already held a perfectly good answer.
The lesson I took: "stale" is not a technical default, it is a product decision. Tuning everything for maximum freshness quietly means tuning everything for maximum cost.
The fix
I gave each kind of data a staleness window matched to how often it actually changes. Reference data that changes rarely is now served from cache for minutes rather than milliseconds, so navigating between views stopped re-firing the same requests. Redundant calls dropped by roughly half.
The rule I held to: make the cheap path the default path, and write down every exception.
The trade-off
Caching moves you from "always right, always slow" to "deliberately, briefly out of date." Cache invalidation is genuinely harder to reason about than fetch-on-render, so this only paid off because the dashboard is used every day and the staleness windows were chosen, not guessed.
What I would do differently
Add request deduplication at the route level and prefetch the breakdown a user is most likely to open next, so the first navigation is fast too, not just the repeats. And put a performance budget in CI, so a regression gets caught before anyone feels it.