Fixing Frozen Price Charts on a Trading Platform with Caching and a Credit Budget

An online trading platform, built in PHP and JavaScript on cPanel hosting, had a visible and embarrassing fault: the live price charts froze. Not slowly degraded — froze, mid-session, for users watching a market.

The diagnosis

We traced the price-fetching layer and found it had no caching and no rate limiting at all. Every open browser tab refreshed the live terminal twice per second, and every one of those refreshes went straight out to the Twelve Data API. Two users with three tabs each were enough to exhaust the plan's allowance, and when the limit hit, the charts simply stopped.

We also counted what the site was actually asking for: 34 active symbols, 24 of them requiring Twelve Data — far beyond the five to ten the client believed were in play, and structurally impossible to serve at that refresh rate on the Basic tier. That number, not the code, was the ceiling.

What we built

• Server-side quote caching, so many browser tabs share one upstream request instead of each making their own.
• A per-minute and per-day credit budget on outbound calls, so the platform governs its own consumption rather than discovering the limit by hitting it.
• Adaptive refresh pacing that slows the polling rate as the remaining quota falls.
• Automatic back-off that serves the last good price rather than freezing — a chart a few seconds stale is a working chart; a frozen one is an outage.
• Cached candle history, so chart redraws stop re-fetching data that has not changed.

Outcome

The fix was deployed and tested live on the client's site. He confirmed it and released the milestone: "Thanks a lot, Marc! Appreciate your fast and clean work... Left you a great review too!" — along with a clear picture of what his current API tier can and cannot support at his symbol count.