Caching ERP Dashboards Without Hiding Stale Data

A dashboard can feel fast while showing the wrong picture of the business. Before caching an ERP query, I would ask what decision the user makes from that number and how old it can be before the decision becomes unreliable.

An overdue-invoice chart and an instruction to release stock should not automatically share a freshness policy.

Define Freshness Per Use Case

For an illustrative dashboard, I would propose three separate contracts:

A monthly sales trend can use a periodically refreshed reporting snapshot.
An operational receivables summary shows when its data was generated and offers a refresh action.
A stock-release command validates availability against authoritative data as part of the write workflow.

These are design choices to agree with business users, not universal expiry settings. I would write the chosen freshness requirement beside each query before deciding whether to cache it.

Understand What Cache-Aside Provides

With cache-aside, the application checks the cache first, reads the data store on a miss, and populates the cache. Expiration and invalidation determine when cached values are replaced. The pattern does not guarantee consistency between the cache and the source. Microsoft's cache-aside guidance also explains why updating the data store before invalidating a cached item matters.

That still leaves races: an overlapping reader can repopulate an old value. Where the business needs stronger consistency, I would change the read or update design instead of promising that a short expiry solves it.

Make the Key Describe the Result

For a branch-level receivables summary, an illustrative key might be:

receivables:v2:tenant-42:branch-7:currency-BHD:period-2026-07

The application must derive and authorize tenant and branch access before reading the cached value. A tenant identifier in a key is not an authorization check. If different users can see different rows, the cache design must account for that visibility too.

I would cache a result object containing both the numbers and their generation timestamp. Relabeling an old snapshot with the current request time would make the interface misleading.

Choose an Honest Failure State

If the cache is unavailable, allowing every dashboard request to run an expensive aggregation could overwhelm the database. My design would include bounded refresh concurrency and a deliberate fallback policy.

For a trend chart, an explicitly labeled previous snapshot might be acceptable. For an operational action, I would prefer an unavailable state to a guessed answer. Those choices should be visible in acceptance criteria.

Measure More Than Cache Hits

I would track source-query duration, refresh failures, snapshot age, and how often users request fresher data. A high hit rate is not success if users routinely export the data because they do not trust the screen.

The goal is a dashboard that is fast enough and clear about what its numbers mean.