Data-Level Isolation

Beyond database schemas, namespace boundaries, and network policies, the MATIH Platform enforces tenant isolation at the data level in caches, event streams, object storage, and search indexes. This page documents how tenant isolation is maintained across all data stores.

Cache Isolation (Redis)

Redis keys are namespaced by tenant to prevent cross-tenant cache pollution:

The TenantAwareCacheManager automatically prefixes all keys:

public class TenantAwareCacheManager {
    private String buildKey(String key) {
        String tenantId = TenantContext.getCurrentTenantIdOrDefault("system");
        return tenantId + ":" + key;
    }
}

Event Isolation (Kafka)

Kafka events carry tenant context in two places:

This double encoding ensures that even if a consumer processes events from a shared topic, it can filter by tenant.

Object Storage Isolation (MinIO)

Objects are isolated by tenant-prefixed paths:

Bucket policies restrict access to the tenant's prefix.

Search Index Isolation (Elasticsearch)

Elasticsearch documents include a tenant_id field, and all queries include a tenant filter:

{
  "query": {
    "bool": {
      "must": [
        {"match": {"action": "QUERY_EXECUTED"}},
        {"term": {"tenant_id": "acme-corp"}}
      ]
    }
  }
}

Vector Store Isolation (Qdrant)

Vector search results are filtered by tenant ID in the metadata payload:

{
  "vector": [0.1, 0.2, ...],
  "filter": {
    "must": [
      {"key": "tenant_id", "match": {"value": "acme-corp"}}
    ]
  },
  "limit": 5
}

Graph Store Isolation

Graph database queries include tenant filters:

MATCH (t:Table)-[:HAS_COLUMN]->(c:Column)
WHERE t.tenant_id = 'acme-corp'
RETURN t.name, c.name

Session Isolation

User sessions are scoped by tenant in Redis:

Session data can only be accessed with the matching tenant context.

Isolation Verification

Related Pages

• Database Isolation -- Schema-level PostgreSQL isolation
• Network Isolation -- Network-level isolation
• Tenant Context -- Application-level context propagation