Caching

Multi-tier event signature caching with Redis L1 and PostgreSQL L2

Multi-Tier Caching

Quint uses a two-tier caching system to avoid re-scoring identical events. Events are hashed by their essential fields (action, target, data fields, agent type) to produce a signature. If the same signature has been scored before, the cached result is returned instantly.

Architecture

Event arrives → Compute signature hash
                    │
              ┌─────┴──────┐
              │  L1: Redis  │ ← TTL: 24 hours
              └─────┬──────┘
                    │ miss
              ┌─────┴──────────┐
              │  L2: PostgreSQL │ ← TTL: 7 days
              └─────┬──────────┘
                    │ miss
              ┌─────┴──────┐
              │  Score event │ → Write back to L1 + L2
              └─────────────┘

Signature Hashing

The cache signature is computed from event essentials — fields that determine the score outcome:

signature_fields = {
    "action": event.action,
    "agent_type": event.agent.agent_type,
    "target_resource_type": event.target.resource_type,
    "sensitivity_level": event.target.sensitivity_level,
    "data_fields": sorted(event.data_fields_accessed),
    "mcp_verified": event.mcp_context.is_verified
}

signature_hash = sha256(json.dumps(signature_fields, sort_keys=True))

Fields NOT included in the signature (they don’t change the score):

• event_id (unique per event)
• timestamp (temporal modifier uses baseline, not absolute time)
• session_id (session context is separate)

Cache Tiers

L1: Redis

Setting	Default	Description
TTL	86,400 seconds (24h)	How long cached scores persist
Max per customer	10,000	Maximum cached events per customer

Eviction: LRU within the per-customer limit. When a customer exceeds 10,000 cached events, the least recently used entries are evicted.

L2: PostgreSQL

Setting	Default	Description
TTL	7 days	How long cached scores persist

Uses the event_cache table with a unique constraint on (customer_id, signature_hash).

Cache Manager API

from src.cache.manager import CacheManager

manager = CacheManager(redis_client, db_session)

# Check cache before scoring
cached = await manager.get(customer_id, signature_hash)
if cached:
    return cached  # Cache hit — skip scoring entirely

# After scoring, write to cache
await manager.set(customer_id, signature_hash, score_response)

Cache Hit Rate

The cache_hit field in score responses indicates whether a cached result was used:

{
  "event_id": "evt-003",
  "score": 12,
  "risk_level": "low",
  "cache_hit": true,
  "scoring_source": "graph_reasoner"
}

Typical cache hit rates vary by customer:

• High repetition workloads (CI/CD bots, monitoring agents): 60-80% hit rate
• Diverse workloads (user-facing agents, varied tasks): 20-40% hit rate