Optimizing TVView’s Auto‑Refresh to Preserve Neon Compute Headroom

核心亮点：一次看似不起眼的刷新间隔调整，竟帮开发者省下大笔云数据库费用，还避免了服务宕机风险。通俗解读：有个叫TVView的仪表盘，原本每30秒就自动问数据库要一次数据，导致数据库以为业务很忙，不敢进入休眠状态，白白烧钱。开发者之前尝试过缓存、手动刷新等方法，但要么没解决根本问题，要么用户体验变差。最后发现最简单有效的办法，就是把刷新间隔从30秒改成5分钟，再改成15分钟——因为数据本身变化不频繁，根本没必要那么频繁地去查。改一个数字，问题就解决了。实际影响：这件事对普通用户来说可能感受不到直接变化，但它揭示了一个重要趋势：云服务按用量计费，很多后台程序都在不知不觉中浪费资源。未来越来越多应用会走向更智能的按需刷新，企业降低成本的同时，用户也能享受到更稳定的服务——毕竟数据库休眠后，突发流量反而更容易被自动扩容接住，不会因为资源紧张而卡顿。这也提醒我们，技术优化有时并不复杂，找到根源，小改动也能带来大收益。

<h1> Optimizing TVView’s Auto‑Refresh to Preserve Neon Compute Headroom </h1> TL;DR: I increased the <code>/tv</code> dashboard refresh interval from 30 s to 5 min and from 5 min to 15 min to prevent unnecessary Neon compute usage, which caused a scale‑to‑zero failure during a recent incident. The change is a single constant swap in <code>src/features/tv/TVDashboard.tsx</code>, but it had a measurable impact on cost and reliability. <h2> The Problem </h2> During a recent Neon incident the <code>/tv</code> dashboard was polling the database every 30 seconds. Neon’s autoscaling policy interprets sustained high query rates as a signal that the database must stay warm, preventing it from scaling to zero. This caused: <ul> <li> Higher compute costs: Neon kept a compute instance alive for longer than needed.</li> <li> Potential throttling: The database was hitting its per‑second request quota.</li> <li> Unnecessary latency: Clients were receiving stale data more often than necessary.</li> </ul> The symptom was a spike in Neon’s billing and a warning in the logs about “scale‑to‑zero prevented due to high activity”. <h2> What I Tried First </h2> Initially I tried to cache the results on the client side using <code>react-query</code>’s stale‑while‑revalidate strategy. I added a <code>staleTime</code> of 5 min and set <code>refetchInterval</code> to 30 s. However, this still triggered a database query every 30 s because <code>react-query</code> would automatically refetch regardless of cache status. The logs still showed high query counts. Next, I tried disabling the auto‑refresh entirely and letting users click a “Refresh” button. While this eliminated the background load, it was a poor user experience; the dashboard looked stale, and users complained. Finally, I considered moving the polling logic to a server‑side cron job that would write fresh data to a cache store. That would have required a new infrastructure component and increased complexity, so I decided to keep the client‑side polling but reduce its frequency. <h2> The Implementation </h2> The core change was a single constant in <code>src/features/tv/TVDashboard.tsx</code>. The file originally defined: <div class="highlight js-code-highlight"> <pre class="highlight tsx"><code>// src/features/tv/TVDashboard.tsx const REFRESH_MS = 30_000; // 30 s — data only changes on manual sync, no need to poll faster </code></pre> </div> I updated it twice: <ol> <li> First bump (30 s → 5 min) – to stop the aggressive polling that prevented Neon from scaling to zero: </li> </ol> <div class="highlight js-code-highlight"> <pre class="highlight tsx"><code>// src/features/tv/TVDashboard.tsx const REFRESH_MS = 300_000; // 5 min — data only changes on manual sync, no need to poll faster </code></pre> </div> <ol> <li> Second bump (5 min → 15 min) – to give Neon even more headroom after the incident: </li> </ol> <div class="highlight js-code-highlight"> <pre class="highlight tsx"><code>// src/features/tv/TVDashboard.tsx const REFRESH_MS = 900_000; // 15 min — data on </code></pre> </div> The <code>useClock</code> hook and the <code>useEffect</code> that se