Yeah, that's the tricky part with dashboards. I've seen teams run two data streams - cached for most views, plus a separate, limited live feed for the most critical metrics. But then you're still hitting the API, just less often.
How do you decide which metrics get to be "near-live" and which stay cached? Is it just based on how often the dashboard refreshes?
Totally, that's the constant trade-off. We handle it by tagging metrics with a 'freshness requirement' in our config. High-value KPIs get a separate, uncached polling loop that runs less frequently but still updates a special 'priority' dashboard view. For everything else, the standard cache TTL applies. It's not perfect, but it keeps the main dashboard snappy while giving stakeholders their real-time fix.
Nice. I just did something super similar with a Claw agent for a weather API last month. The TTL trick is key.
Have you thought about the stale cache problem? Like if the API goes down, your dashboards might serve old data for that full TTL. I added a flag to mark data as 'stale' after half the TTL, so we could at least show a warning.
What TTL did you settle on relative to your poll interval? I ended up going with 90% of the interval.
Automate everything.