Every cache in production today operates on a handshake agreement: you set a TTL, and the cache promises to evict the key when the timer expires. That is the entire contract. There is no guarantee the data was fresh at any point during the TTL window. There is no audit trail. There is no alerting when data goes stale. There is no compliance report you can hand to an auditor. For regulated industries — finance, healthcare, government — this is not acceptable. We built what is missing: per-key freshness contracts that the cache engine enforces, monitors, and reports on.
TTL Is Not a Freshness Guarantee
TTL tells the cache when to evict a key. It says nothing about when the key was last refreshed. A key with a 60-second TTL might contain data that is 59 seconds stale, and no system will notice, alert, or log it. The value sits in the cache, silently wrong, until the timer runs out and someone re-fetches.
This model works for content that tolerates staleness — blog posts, marketing pages, static assets. It does not work for data with real-time correctness requirements: financial prices, patient records, inventory counts, trading positions, account balances. For these keys, “stale for up to 59 seconds” is not a rounding error. It is a regulatory violation, a financial loss, or a clinical risk.
The problem is structural. TTL is a timer, not a contract. It does not guarantee freshness. It does not measure freshness. It does not report freshness. It is a best-effort expiration mechanism bolted onto a key-value store. Every cache system — Redis, Memcached, Hazelcast, Caffeine — uses this same model. None of them offer anything better.
Regulated Industries Cannot Trust Best-Effort
SOC 2 auditors are now asking about cached data. The question is straightforward: “How do you ensure that cached data reflects the current state of the source system?” When the answer is “we set a TTL and hope for the best,” the conversation does not go well.
FINRA requires audit trails on financial data, including data served from caches. If a trading platform serves a stale price from cache, the platform needs to prove it was fresh at the time of the trade, or explain why it was not. Today, no cache produces this evidence.
HIPAA mandates that patient data be current. A clinical system that caches patient vitals must guarantee those values reflect the latest readings. A 30-second TTL on patient data is not a HIPAA-compliant freshness strategy — it is a liability.
E-commerce platforms that cache inventory counts oversell products every time the cache is stale. Every oversell triggers a refund, a customer service ticket, and a trust loss. The cost of stale inventory data is directly measurable in dollars per minute.
None of these industries can accept “best-effort.” They need enforceable guarantees, violation tracking, and compliance evidence. Caching has never offered any of these.
Cache Contracts: Per-Key SLAs with Teeth
A cache contract is a freshness SLA attached to a specific key at write time. The syntax is a single modifier on the SET command:
SET user:123:balance <value> SLA FRESH_WITHIN 100ms REFRESH_FROM GET /api/users/123/balanceThis tells the cache engine three things: (1) this key must never be older than 100ms, (2) when the freshness window is about to expire, refresh the value by calling the specified source, and (3) if the refresh fails, fire an alert and log the violation.
The engine does not wait for the key to expire. It schedules a proactive refresh before the 100ms window closes. The value is always fresh when a client reads it — not because of lucky timing, but because the engine enforced the contract. If the source is unreachable, the engine fires an alert before any client sees stale data. Every refresh, every violation, and every recovery is logged with a timestamp, the key name, the contract terms, and the source response code.
Composition with CDC and Dependency Graphs
Cache contracts do not replace CDC auto-invalidation or the causal dependency graph. They compose with them.
CDC provides event-driven freshness. When a database row changes, CDC invalidates the corresponding cache key immediately. But CDC depends on the database change event actually firing. If the source is not a database (an API, an external feed, a computed value), CDC cannot help. If the CDC pipeline has latency, there is a window of staleness.
Cache contracts provide time-bound freshness. Regardless of whether a CDC event fires, the engine guarantees the value will be refreshed within the contracted window. If CDC fires first, the contract is satisfied early. If CDC is delayed or unavailable, the contract catches it. Together, they provide both reactive and proactive freshness — zero gaps.
The dependency graph propagates contracts to derived keys. When a contracted key participates in a dependency graph, the freshness guarantee cascades. If user:123:dashboard has a 100ms FRESH_WITHIN contract and depends on user:123:balance, the engine ensures the balance is fresh before refreshing the dashboard. The contract follows the causal chain, not just the individual key.
The Compliance Pitch
Imagine walking into a SOC 2 audit and handing the auditor a report that says: “Over the past 90 days, our cache maintained 99.97% contract compliance across 14,200 contracted keys. There were 3 violations, all on the stock:* prefix, caused by a source API timeout on March 14. Mean freshness across all contracted keys was 34ms. P99 staleness was 82ms. Every refresh event is logged with timestamps and source response codes. Here is the exportable report.”
That is a different conversation from “we set TTLs and we think the data is usually fresh.”
The compliance dashboard exposes contract compliance percentage, violations per key prefix, mean freshness, p99 staleness, and refresh success rate. Metrics are available via the dashboard, the API, and as exportable CSV/JSON. Violation logs include the key name, the contract terms, the refresh timestamp, the source response code, and the resolution time. This is the evidence that SOC 2, FINRA, and HIPAA auditors require.
Why Nobody Else Has This
Redis offers TTL and nothing else. There is no per-key SLA, no proactive refresh, no violation alerting, and no compliance metrics. TTL is fire-and-forget. When the timer expires, the key is gone. What happened between SET and expiry is invisible.
Memcached has the same model. Keys expire by TTL. There is no freshness tracking, no refresh mechanism, and no audit trail. Memcached was designed as a simple volatile store. Compliance was never in scope.
Caffeine and Guava offer refreshAfterWrite, which is the closest analog. But it is local-only (single JVM), has no distributed propagation, no violation alerting, no compliance metrics, and no audit log. It is a local refresh heuristic, not an enforceable SLA.
CDNs (CloudFront, Fastly, Akamai) use TTL and stale-while-revalidate headers. These are HTTP-level hints, not enforceable contracts. There is no per-key SLA, no violation tracking, and no compliance reporting. A CDN cannot tell you whether a specific key was fresh at a specific time.
No caching system — distributed, local, or CDN — offers per-key freshness contracts with proactive refresh, violation alerting, and compliance metrics. This is a category of functionality that has not existed until now.
Related Reading
Also Read
Make Your Cache Auditable.
Per-key freshness contracts. Proactive refresh. Compliance metrics. Enforceable SLAs for every key that matters.
Start Free Trial Schedule Demo