Define freshness contracts per key. The engine enforces them — proactively refreshes before expiry, alerts when contracts can't be met, reports compliance metrics. Auditable caching for regulated industries.
TTL expires and you hope someone re-fetches. There is no guarantee the data is fresh, no audit trail proving it was fresh, and no alerting when it goes stale. For regulated industries, this is not acceptable.
You attach a freshness SLA to any cache key at write time. Cachee's contract engine schedules proactive refreshes, monitors compliance, and logs every event.
TTL waits for the key to expire and then hopes someone fetches fresh data. Cache contracts are proactive. The engine schedules a refresh before the contract window closes. The value is always fresh when you read it — not because you got lucky on timing, but because the engine guaranteed it.
If the refresh source is unreachable or returns an error, the engine fires an alert immediately. You know the contract is at risk before any client sees stale data. TTL gives you silent staleness. Contracts give you loud failures.
Every proactive refresh, every contract violation, every source failure, and every recovery is logged with a timestamp and the key name. This log is the audit trail that regulated industries require and no cache has ever provided.
The difference between “we think the data was fresh” and “here is the timestamped proof that the data was refreshed 47ms before the contract window closed, from this source, with this response code” is the difference between failing an audit and passing one.
Cache contracts expose real-time compliance metrics for every key and every prefix. Exportable reports. API access. Zero manual tracking.
An SLA is only trustworthy if there’s a defined degradation behavior. Cache Contracts include write-through backpressure — principled answers for what to serve and for how long when the source system can’t keep up.
If refresh latency exceeds the contract threshold, Cachee serves the last-known value and marks it DEGRADED. The refresh continues in background. No blocking, no timeout cascade.
If the source is unreachable, Cachee serves stale data for a configurable GRACE_PERIOD (e.g., 30s, 5m). After grace expires, returns an error rather than silently serving data that’s too old. You choose the policy.
Every degradation event is logged with timestamp, key, contract, actual staleness, and source response time. Dashboard shows: degradation %, grace period usage, source health score. The audit trail is complete even during failures.
SET price:AAPL 182.50 SLA FRESH_WITHIN 100ms REFRESH_FROM GET /api/prices/AAPL GRACE_PERIOD 30s ON_DEGRADE SERVE_STALE ON_EXPIRE RETURN_ERRORCache contracts turn caching from a liability into a compliance asset in industries where stale data has consequences.
Cache contracts are not a standalone feature. They compose with CDC, dependency graphs, and coherence to provide freshness guarantees at every layer.
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.No caching system offers per-key freshness contracts, compliance metrics, or proactive refresh with violation alerting. Here is the landscape.
| Platform | Freshness Model | Cachee Cache Contracts |
|---|---|---|
| Redis | TTL only — fire-and-forget, no audit trail | Per-key SLA with proactive refresh + compliance log |
| Memcached | TTL only — no SLA model, no metrics | FRESH_WITHIN contracts with violation alerting |
| Hazelcast | Near-cache TTL — no per-key SLA, no compliance | Per-key freshness guarantees + exportable reports |
| Caffeine / Guava | refreshAfterWrite — local only, no compliance metrics | Distributed SLA enforcement + full audit trail |
| Every L1 / CDN Cache | No freshness guarantee, no compliance reporting | Enforceable, auditable, per-key freshness contracts |
Cache contracts are per-key freshness SLAs that you define at write time using the FRESH_WITHIN modifier. When you SET a key with a freshness contract, Cachee guarantees that the cached value will never be older than the specified duration. The engine proactively refreshes the value before the contract expires, alerts when it cannot meet the SLA, and logs every refresh and violation for compliance reporting.
FRESH_WITHIN is a modifier on the SET command that establishes a freshness contract. For example: SET user:123:balance <value> SLA FRESH_WITHIN 100ms REFRESH_FROM GET /api/users/123/balance. The engine schedules a proactive refresh before the 100ms window expires. If the refresh source is unreachable, an alert fires and the violation is logged. The cached value is never served past its contract without explicit acknowledgment.
No. Reads are identical to any other cache GET — sub-microsecond, zero overhead. The freshness contract is enforced asynchronously by the engine's refresh scheduler. The scheduler runs a background timer per contracted key and triggers the refresh before the contract window expires. The only work is the background refresh itself, which happens entirely outside the read path.
CDC and cache contracts are complementary. CDC invalidates keys when the source database changes (event-driven freshness). Cache contracts guarantee that even without a CDC event, the value will be refreshed within the contracted window (time-bound freshness). Together, they provide both reactive and proactive freshness. If CDC fires before the contract window, the value is already fresh. If CDC is delayed or the source is not a database, the contract catches it.
Cachee exposes per-key and per-prefix compliance metrics: contract compliance percentage, total violations, mean freshness age, p99 staleness, refresh success rate, and a full audit log of every refresh and violation event with timestamps. These metrics are available via the dashboard, the metrics API, and as exportable CSV/JSON reports suitable for SOC 2, FINRA, and HIPAA audits.
Per-key freshness contracts. Proactive refresh. Compliance metrics. The cache SLA that regulated industries have been waiting for.