Caching And Cache Keys

In server-side Pivot, caching is critical for performance and cost management. Analytical queries can be expensive and slow; deduplicating identical requests ensures that the backend only performs the work once.

RevoGrid Pivot uses deterministic cache keys to identify identical analytical windows.

What Is A Cache Key?

A cache key is a unique string that represents the exact state of an analytical request. If any part of the request changes (filters, grouping, viewport, or data version), a new key is generated.

This allows both the client-side HttpPivotRemoteStore and your backend analytical engine to:

Deduplicate: Prevent multiple identical requests from hitting the database simultaneously.
Memoize: Return previously computed results for the same analytical window.
Invalidate Safely: Ensure that if the underlying data or field definitions change, old cached results are never shown.

Key Components

A stable Pivot cache key is composed of several semantic layers:

Component	Description	Why It Matters
`tenantId`	Identifies the client or organization scope.	Prevents data leakage between different users/tenants.
`viewId`	Identifies the specific analytical view or dashboard.	Keeps caches separate for different reports using the same fields.
`fieldsVersion`	A checksum or version of the field registry.	If you change a field’s calculation or data type, old summaries must be invalidated.
`datasetWatermark`	A timestamp or batch ID representing data freshness.	Automatically invalidates the cache when new data is loaded into the warehouse.
`request`	A stable stringification of filters, rows, columns, and windows.	Ensures that changing a single filter or scrolling the viewport yields a specific key.

How Keys Are Generated

RevoGrid provides a standard createPivotCacheKey utility that builds these keys. It uses a stable stringification algorithm, meaning that the order of keys in a JSON object does not change the resulting string.

1
// Internal logic simplified
2
const cacheKey = `pivot:${tenantId}:${viewId}:${fieldsVersion}:${datasetWatermark}:${stableStringify(request)}`;

Stable Stringification Example

Even if the UI sends filters in a different order, the cache key remains the same:

1
// Request A
2
{ filter: { region: 'US', category: 'Tech' } }
3

4
// Request B
5
{ filter: { category: 'Tech', region: 'US' } }
6

7
// Both result in the same stable key:
8
// "...:{"category":"Tech","region":"US"}"

Observing Cache Status

When using HttpPivotRemoteStore or the recommended backend response format, the grid receives cache metadata in the meta object:

1
{
2
  "data": [...],
3
  "meta": {
4
    "cacheKey": "pivot:tenant-1:sales:v1:20240424:...",
5
    "cacheStatus": "hit", // or 'miss', 'warm', 'bypass'
6
    "elapsedMs": 12
7
  }
8
}

This is useful for UI diagnostics and understanding whether your analytical engine is performing efficiently.

Best Practices

Keep viewId Stable: Do not use random IDs for views if you want users to benefit from shared caching across sessions.
Update datasetWatermark: Your backend should provide a watermark (like a max(updated_at) or a batch ID) to the client so the cache key updates automatically when data changes.
Normalize Requests: If you are implementing a custom PivotRemoteStore, ensure you normalize filters and descriptors before generating keys to maximize cache hits.