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 is the shared cache and control plane; 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 Redis.
- 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.
Metadata informs policy
Rhai hooks can inspect directly written tables and, when safe, use more specific conditions.
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 Redis-backed results. 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 1.9 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.
Its transport model is explicit: native proxy and Redis connections do not provide TLS. Put the proxy, backend, and Redis on a trusted private network or add network-layer encryption and edge controls.
Read cache behavior and consistencyRead 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.