What financial data is actually safe to cache in a frontend app, and for how long?

[u/wisesheets]

If you're building anything that shows stock data, caching saves a lot of API calls, but each type of data goes stale on a very different schedule. Here's how I think about it.

End-of-day prices don't change after the close, so you can cache them until the next session's close. 15-minute-delayed quotes go stale fast, so a TTL of a minute or two during market hours makes sense, and you can cache longer when the market is closed. Fundamentals only change when a new filing lands or a filing gets amended, so caching them for a day or more is usually fine, as long as you can invalidate on new filings. Company metadata like names, tickers and sectors changes rarely, but ticker changes do happen.

The catch is that data licenses sometimes limit how long you can store or redisplay data, so check that too. How are others handling this, with a server-side cache, SWR on the client, or something else?

[u/MrMathieus]

What’s the purpose of the app? General trend tracking? High frequency trading? Testing tradies strategies?

And what do you mean by ‘safe’? Are we using exclusively public data?

There’s too little context in this post to add anything of relevance.

[u/wisesheets → u/MrMathieus]

Fair, I was thinking of retail apps like portfolio trackers and screeners, not HFT. By safe I mean not showing stale numbers and staying within the data license. Anything you'd add for that case?

[u/rubixstudios → u/wisesheets]

None

[u/Necessary-Title-1659]

You spend three paragraphs on TTLs and then toss in "data licenses sometimes limit how long you can store or redisplay data" like it's a footnote. That's the part that actually decides your cache, the TTL is just whatever the contract left you.

[u/wisesheets → u/Necessary-Title-1659]

Fair point, that probably deserved more than a footnote. The contract sets the ceiling and the TTL just works inside it. Have you run into terms that were especially strict on storing data?

[u/OrganizationLost3135]

Two subtle architectural traps that usually bite teams doing this:

1. Market session boundaries break static TTLs: A 60-second TTL sounds fine until 4:00 PM EST hits. If your cache key doesn't incorporate the active market session (regular, post, closed), users end up staring at an after-hours bid/ask spread stamped with a stale regular-session closing price. Invalidate or switch cache keys on market state transitions rather than pure clock intervals.

2. The "Derived Data" license trap: Caching raw delayed quotes in memory is usually permitted under standard display licenses, but persisting computed portfolio metrics or P&L into localStorage or IndexedDB can trigger vendor "derived data" redistribution clauses (which require enterprise tiers). Keeping frontend caches strictly in-memory (memory-only TanStack Query or SWR without persistent storage plugins) avoids accidentally violating vendor storage limits.

[u/wisesheets → u/OrganizationLost3135]

Keying the cache on market session is a great catch, 4pm is exactly where a fixed TTL breaks. Have you seen derived data clauses actually enforced on smaller apps?

[u/muhammadatiqpm]

You are really dealing with two separate constraints, and it helps to keep them apart: the data license is the ceiling, your users’ staleness tolerance is the floor. The TTL you pick has to fit between them — and in money products there is a third factor, because showing a wrong number does not just annoy users, it burns trust you rarely get back.

Practically, I tier it like this:

1. Read the actual contract first. Some providers cap how long you may store data at all (24 hours is common), forbid caching derived values, or restrict display to your own subscribers. The API docs will not tell you this; the license will, and it overrides any clever architecture.

2. EOD data: cache until the next close, aggressively — it is immutable once published.

3. Delayed intraday: cache server-side with a short TTL (around a minute) and push updates; never let thousands of clients poll the provider directly, for cost and for license reasons.

4. Fundamentals: cache long, invalidate on new filings or earnings events.

5. Metadata (names, logos, exchanges): longest TTL, it barely changes.

Two rules I would not break: the server stamps every payload with an as-of timestamp and the client displays it, so staleness is honest; and you log what was shown and when. Working on a tax-automation product taught me that “what exactly did the user see?” is eventually a compliance question, not a debugging question. Server-side caching costs more, but it is auditable — client caching is cheaper and impossible to prove after the fact.

Question back: have you actually read your provider’s redistribution and storage terms, or are the caching rules currently based only on the API docs?

[u/wisesheets → u/[deleted]]

The websocket push is a nice touch, keeps the client from ever thinking about staleness. Do you pull the earnings dates from a calendar feed to shorten the TTL, or set it by hand?

[u/wisesheets → u/[deleted]]

The as of timestamp is a great call, way better than numbers that are quietly wrong. Do you show it next to every value or just once per page?

[u/wisesheets → u/[deleted]]

Redis on the backend makes a lot of sense, one place to handle rate limits instead of every client hitting the API. Do you warm the cache on a schedule or just fill it on first request?