Cache
Introduction
PactFlow On-Premises requires a storage engine compatible with the Redis Serialization Protocol (RESP) to support the following functions:
User session management
UI caching for improved performance
Session management
User sessions are kept in Redis. The browser only gets a 128-bit session ID.
This ID is valid for 30 days.
It’s signed with a server-side secret so it can’t be faked or modified.
Even if the cookie sticks around longer, the server won’t accept it after 30 days.
This helps protect against cookie replay attacks.
All user data, including idToken and accessToken, is stored server-side and is never exposed to the user.
Caching
To improve UI performance, PactFlow On-Premises uses a server-side caching layer.
This might cause temporarily outdated content. What users see can vary depending on when the data was last fetched, so different users or browser sessions might see slightly different versions of the content.
PactFlow On-Premises uses a per-user server-side cache, following a stale-while-revalidate strategy:
Hot cache: Data is used without validation.
Warm cache: Data is served immediately, and the cache is refreshed in the background.
Cold cache: The UI blocks until data is fetched from the API.
This approach balances performance and freshness.
When a user writes data through the UI, their entire user cache is immediately invalidated. This ensures correctness for the current user. However, if the change is made by another user or by using the API, it may take longer to appear.
As a fallback, the PactFlow On-Premises UI follows HTTP cache-control conventions. If a user performs a hard refresh (Shift + Refresh), the browser sends headers like Cache-Control: no-cache or Pragma: no-cache, which bypass the cache.
Supported versions
Engines that implement the Redis Serialization Protocol (RESP) version 3 are supported.
Example implementations include:
Redis
Valkey