Write reaches the backend
INSERT, UPDATE, DELETE, and DDL operations are not served from a cache result.
Architecture in practice
Cache the repeatable read. Keep the database authoritative.
CacheDB is inserted into the database request path. Its mode, policy, metadata, and invalidation decisions determine when a result may be reused and when a request must return to the backend.
Request flow
One request path. Two possible read outcomes.
The backend database remains the source of truth. Redis Community, Valkey or Redis Enterprise can provide the shared cache; the proxy makes the decision for each eligible request.
- 01
Application request
The client connects through a selected CacheDB protocol path.
- 02
Parse and classify
CacheDB identifies the statement, tables, parameters, transaction state, and policy context.
- 03
Cache check
For an eligible read in full mode, it derives a key and checks the shared cache.
- 04
Reply or backend read
A hit returns the stored response. A miss reaches the backend, whose successful response can be stored for later reuse.
Write path
Changes trigger deliberate invalidation.
Write operations go to the backend. After completion, CacheDB can use parsed metadata and policy to invalidate cache entries related to the tables that changed.
Hooks apply policy
Scripts can inspect the tables a change affects and, when safe, invalidate only the relevant cached results.
Conservative fallback remains available
When predicate metadata is incomplete, invalidate the written-table scope rather than guessing.
Deployment mode
Start by observing.
Transparent
Observe without reusing results.
CacheDB parses requests and records metadata, monitoring, and metrics, but does not serve or store cached query results. Use it to validate compatibility and baseline behavior.
Full
Reuse results where policy permits.
Eligible reads can use results from the configured distributed cache. Full mode requires valid licensing and a workload-specific policy for TTL, bypass, and invalidation.
Boundaries and degraded behavior
CacheDB should be designed into the operational model.
CacheDB documents eventual consistency for cached reads. It should not be used for strict state such as locks, sessions, feature flags, or other data that must always be read from the backend.
Native proxy connections support TLS on both database legs, with backend certificate verification by default. Cache and metrics connections do not support TLS, so keep them on a trusted private network or add network-layer encryption. Place the console behind a TLS-terminating reverse proxy or WAF.
Explore CacheDB capabilitiesReview security boundariesA controlled evaluation
Validate the path before broadening it.
Use transparent mode and a representative workload to establish a baseline, then agree the policy and measurements for an evidence-led full-cache test.