# Caching

A page load in Rebask can involve several cache boundaries. The server may reuse rendered HTML, RSC
payloads, or data, while the client router may cache route segments for faster navigations. These
caches are related, but they store different values and are not interchangeable.

| Cache                                                  | Stores                                                                |
| ------------------------------------------------------ | --------------------------------------------------------------------- |
| [Page Caching](./page-caching.md)                      | Rendered HTML and PPR shells                                          |
| [RSC Caching](./rsc-caching.md)                        | Server-rendered RSC payloads and shells for pages and layout segments |
| [Caching in Server Components](./server-components.md) | `"use cache"` results, `durableCache` data                            |
| [Segment Caching](./segment-caching.md)                | Rendered route segments and RSC shells retained by the client router  |

All server caches use the same [APIs to set lifetimes, attach tags, and trigger revalidation](./cache-lifetimes.md).

The client router has separate APIs to control the freshness, tags, and revalidation of route
segments it retains in the browser, whether they arrive with the initial page, through prefetching,
or during a later request.

## Server Cache keys

Page, RSC, and `"use cache"` entries are scoped to a
[`deploymentId`](../configuration.md#rebask-deploymentid), which is a way of saying they differ
between builds:

| Cache entry                                                  | Logical key                                                                                                    |
| ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| [Page cache entries](./page-caching.md#page-cache-keys)      | Multiple `ph:<deployment-id>:` keys                                                                            |
| [Page or layout RSC](./rsc-caching.md#how-rsc-caching-works) | `pr:<deployment-id>:<pathname>`                                                                                |
| [Page or layout RSC shell](./rsc-caching.md)                 | `ps:<deployment-id>:<route-file>` or `ps:<deployment-id>:<route-file>:<pathname>` for an individual page shell |
| [`"use cache"` function](./server-components.md#use-cache)   | `du:<deployment-id>:<function-id>:<encoded-arguments>`                                                         |
| [`durableCache` data](./server-components.md#durablecache)   | `dd:<source-hash>:<args-hash>:<deps>`                                                                          |

Every key starts with a two-letter tag whose first letter is `p` for a page's HTML or RSC payload and
`d` for runtime data. A [cache handler](./cache-handler.md) can tell them apart with `isPageCacheKey`
from `@rebask/core/cache`.

> We call it `deploymentId` because it identifies the active deployment across the server and
> client. Rebask uses it to namespace cache keys and provide [skew protection](../production/skew-protection.md),
> allowing the client to detect when it is communicating with a different deployment.

All server cache keys except those created by `durableCache` include `deploymentId` because their
values are tied to the build that produced them. A new build can invalidate those values in several
ways:

- It can change route or component code, environment variables, module IDs, client component
  references, or serialized output
- Some entries contain JSX or RSC payloads with references to components and client modules from the
  build that created them. Reusing those entries after a build change could point to incompatible or
  missing code.

Using a new `deploymentId` for every build avoids tracking all of those dependencies individually. It
gives each build a new cache namespace.

See [Cache Handler](./cache-handler.md) to configure the storage backend for Rebask's server cache.

## Caching in Development

In development, Rebask uses a no-op cache, effectively disabling caching, so every request renders
fresh. The client router still caches route segments in the browser's memory.