# Caching And Cache Keys
URL: https://pro.rv-grid.com/guides/pivot/server-side/caching/
Source: src/content/docs/guides/pivot/server-side/caching.mdx
Description: Understand how RevoGrid Pivot generates deterministic cache keys for safe and efficient remote analytical execution.
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:

1. **Deduplicate**: Prevent multiple identical requests from hitting the database simultaneously.
2. **Memoize**: Return previously computed results for the same analytical window.
3. **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.

```ts
// Internal logic simplified
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:

```ts
// Request A
{ filter: { region: 'US', category: 'Tech' } }

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

// Both result in the same stable key:
// "...:{"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:

```ts
{
  "data": [...],
  "meta": {
    "cacheKey": "pivot:tenant-1:sales:v1:20240424:...",
    "cacheStatus": "hit", // or 'miss', 'warm', 'bypass'
    "elapsedMs": 12
  }
}
```

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.

## Next

- [Server-Side Pivot](/guides/pivot/server-side/)
- [Remote API Reference](/guides/pivot/remote-api-reference/)
- [OLAP Best Practices](/guides/pivot/olap-best-practices/)
