st.cache_data: ttl expiry or manual .clear() for data that updates on a schedule?

I have a Streamlit app (modern st.cache_data/st.cache_resource API) where a cached function reads a dataset that is refreshed by an external job at known times, roughly every few hours. The cache key (function name, arguments, code hash) does not change when the underlying data changes, so without intervention users keep seeing the stale result.

I'm weighing two documented approaches and can't decide which fits this constraint better. Option one is the ttl parameter, which bounds staleness but only guarantees eventual refresh — a user hitting the app just before expiry still sees data up to ttl seconds old, and a short ttl means paying recomputation cost even when nothing changed. Option two is calling the cached function's .clear() method (or st.cache_data.clear() globally) from an event-driven path, which gives exact freshness but requires the app to know when the external job ran, and a global clear would spike latency for every session on the next run.

Assume a recent Streamlit release; exact parameter names should be checked against the installed version's API reference.

Which approach is more appropriate when data updates on a predictable but externally-triggered schedule?

If I use .clear(), is there a documented pattern for triggering it from outside the app process, or must invalidation happen inside a Streamlit run?

Does max_entries eviction interact with either approach in a way that changes the trade-off?