Cache Key Design - Cache Design Considerations | OneNoughtOne

0/246

System Design (LLD)Cache Design Considerations

Cache Design Considerations

LevelIntermediate

Duration90 mins

TopicCache Design Considerations

1 / 4

Cache Key Design

The Foundation of Every Cache Lookup

Every cache operation—whether a read, write, or invalidation—begins with a single question: What is the key?

The cache key is the identifier that maps your request to the stored data. It might seem trivially simple: just use the user ID, or the URL, or some combination of parameters. But this apparent simplicity conceals profound complexity. A poorly designed key scheme can lead to cache pollution, stale data nightmares, memory exhaustion, security vulnerabilities, and performance pathologies that only manifest at scale.

Principal engineers at companies like Netflix, Google, and Meta spend considerable effort designing cache key schemes. They understand that the key isn't just an identifier—it's the contract between your application and your caching layer. Get it right, and caching becomes invisible infrastructure that simply works. Get it wrong, and you'll spend countless hours debugging mysterious cache misses, inconsistencies, and performance cliffs.

What You Will Learn

By the end of this page, you will understand how to design cache keys that are precise, efficient, and maintainable. You'll learn composition strategies, namespace conventions, collision prevention, versioning techniques, and security considerations that separate amateur caching from production-grade caching infrastructure.

What Makes a Cache Key Effective

An effective cache key satisfies several critical properties simultaneously. Understanding these properties is essential before diving into specific design techniques.

The Five Properties of an Effective Cache Key:

Essential Cache Key Properties

•Uniqueness — The key must uniquely identify the cached data. Two different pieces of data must never share the same key, or cache corruption occurs.
•Determinism — Given the same inputs, the key generation must always produce the same key. Non-deterministic keys lead to cache misses for data that's already cached.
•Completeness — The key must incorporate all factors that affect the cached value. If user preferences affect output, those preferences must be part of the key.
•Minimality — The key should include only the factors that affect the cached value—nothing more. Overspecification reduces cache hit rates.
•Efficiency — Key generation and comparison should be fast. Complex key computation can negate caching benefits.

The Uniqueness-Minimality Tension:

The most common design tension in cache keys is between uniqueness and minimality. Overly unique keys (including too many parameters) fragment the cache, reducing hit rates. Insufficiently unique keys cause cache pollution, where one user's data corrupts another's view.

Consider caching API responses for a product catalog:

Over-Specified Key

•product:123:user:456:session:789:timestamp:1234567890
•Includes user ID, session, and timestamp
•Every request generates a new cache entry
•Effectively disables caching entirely
•Cache hit rate: ~0%

Appropriately-Specified Key

•product:123:locale:en-US:currency:USD
•Includes only factors affecting product display
•Same product/locale/currency shares cache entry
•Maximizes cache hit rate while maintaining correctness
•Cache hit rate: 85%+ typical

The Cost of Getting Keys Wrong

Over-specified keys waste memory and compute by storing redundant copies. Under-specified keys serve incorrect data to users. Both failures can be subtle—you won't see exceptions, just degraded performance or confused users. Always validate your key scheme against real access patterns.

Key Composition Strategies

Cache key composition is the process of constructing keys from component parts. A well-designed composition strategy makes keys predictable, debuggable, and maintainable.

The Three Key Composition Approaches:

Hierarchical keys structure components from general to specific, using a delimiter (typically : or /). This approach mirrors how we think about data relationships and enables pattern-based operations.

Pattern: {service}:{entity}:{id}:{aspect}:{variation}

Examples:

hierarchical-keys.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Hierarchical key examples
const productKey = "catalog:product:12345:details:en-US";
const userKey = "auth:user:67890:profile";
const searchKey = "search:results:electronics:page:1:size:20";
const cartKey = "commerce:cart:user:12345:items";
 
// Benefits:
// 1. Visual hierarchy aids debugging
// 2. Pattern matching for bulk invalidation: "catalog:product:12345:*"
// 3. Clear ownership/namespace boundaries
// 4. Self-documenting structure
 
class CacheKeyBuilder {
    private parts: string[] = [];
    private readonly separator = ":";
    
    constructor(private namespace: string) {
        this.parts.push(namespace);
    }
    
    entity(type: string, id: string | number): this {
        this.parts.push(type, String(id));
        return this;
    }
    
    aspect(name: string): this {
        this.parts.push(name);
        return this;
    }
    
    variation(key: string, value: string): this {
        this.parts.push(`${key}=${value}`);
        return this;
    }
    
    build(): string {
        return this.parts.join(this.separator);
    }
}
 
// Usage
const key = new CacheKeyBuilder("catalog")
    .entity("product", 12345)
    .aspect("details")
    .variation("locale", "en-US")
    .build();
// Result: "catalog:product:12345:details:locale=en-US"

Hierarchical Key Best Practices

Start with the most stable component (service name) and progress to the most variable (specific variations). This enables efficient pattern-based operations like wildcard deletion in Redis: DEL catalog:product:12345:*

Namespace and Prefix Conventions

Namespacing is the practice of organizing cache keys into logical groups. Proper namespacing prevents collisions between different parts of your system and enables targeted cache management.

Why Namespacing Matters:

In a typical production system, multiple services share the same cache infrastructure. Without namespacing:

Service A's user:123 collides with Service B's user:123
There's no way to flush one service's cache without affecting others
Debugging becomes impossible—you can't tell who owns a key
Metrics are meaningless without per-service breakdown

Namespace Hierarchy Levels
Level	Purpose	Example	When to Use
Environment	Separate dev/staging/prod	`prod:`, `staging:`	Multi-environment shared cache
Service	Isolate microservices	`user-service:`, `catalog:`	Always in microservices
Domain	Group related entities	`auth:`, `commerce:`	Large monoliths or domains
Entity	Identify data type	`user:`, `product:`	Always
Version	Handle schema changes	`v2:`, `schema:3:`	During migrations

namespace-conventions.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
/**
 * Production-grade namespace management for cache keys.
 */
interface NamespaceConfig {
    environment: string;
    service: string;
    schemaVersion?: number;
}
 
class CacheNamespace {
    private readonly prefix: string;
    
    constructor(config: NamespaceConfig) {
        const parts = [
            config.environment,
            config.service,
        ];
        
        if (config.schemaVersion) {
            parts.push(`v${config.schemaVersion}`);
        }
        
        this.prefix = parts.join(':');
    }
    
    /**
     * Creates a fully-qualified cache key within this namespace.
     */
    key(...parts: (string | number)[]): string {
        return [this.prefix, ...parts.map(String)].join(':');
    }
    
    /**
     * Returns a pattern for matching all keys in this namespace.
     * Useful for cache invalidation.
     */
    pattern(): string {
        return `${this.prefix}:*`;
    }
    
    /**
     * Creates a sub-namespace for a specific entity type.
     */
    entity(entityType: string): EntityNamespace {
        return new EntityNamespace(this.prefix, entityType);
    }
}
 
class EntityNamespace {
    private readonly prefix: string;
    
    constructor(parentPrefix: string, entityType: string) {
        this.prefix = `${parentPrefix}:${entityType}`;
    }
    
    /**
     * Key for a specific entity by ID.
     */
    byId(id: string | number): string {
        return `${this.prefix}:${id}`;
    }
    
    /**
     * Key for an entity with additional aspects.
     */
    byIdWithAspect(id: string | number, aspect: string): string {
        return `${this.prefix}:${id}:${aspect}`;
    }
    
    /**
     * Pattern for all entities of this type.
     */
    pattern(): string {
        return `${this.prefix}:*`;
    }
    
    /**
     * Pattern for a specific entity (all aspects).
     */
    patternForId(id: string | number): string {
        return `${this.prefix}:${id}:*`;
    }
}
 
// Production usage
const config: NamespaceConfig = {
    environment: process.env.NODE_ENV === 'production' ? 'prod' : 'dev',
    service: 'user-service',
    schemaVersion: 2,
};
 
const cache = new CacheNamespace(config);
const users = cache.entity('user');
 
// Generate keys
const userKey = users.byId(12345);
// "prod:user-service:v2:user:12345"
 
const profileKey = users.byIdWithAspect(12345, 'profile');
// "prod:user-service:v2:user:12345:profile"
 
const preferencesKey = users.byIdWithAspect(12345, 'preferences');
// "prod:user-service:v2:user:12345:preferences"
 
// Invalidation patterns
const allUsers = users.pattern();
// "prod:user-service:v2:user:*"
 
const userMike = users.patternForId(12345);
// "prod:user-service:v2:user:12345:*"

Namespace Design Guidelines

Be explicit — Use full service names, not abbreviations ("user-service" not "us")
Be consistent — Establish conventions and enforce them through shared libraries
Document patterns — Maintain a key pattern registry for debugging
Monitor by namespace — Track hit rates, memory usage per namespace

Handling Key Collisions

Key collisions occur when two different inputs produce the same cache key. This leads to cache corruption where one piece of data is returned for an unrelated request. Understanding and preventing collisions is critical for cache correctness.

Types of Key Collisions:

Collision Sources

•Hash Collisions — Two different inputs hash to the same value. Rare with cryptographic hashes but possible with weak hash functions.
•Missing Parameters — Key generation ignores a parameter that affects the cached value (e.g., forgetting to include user locale).
•Canonical Ordering Issues — Same parameters in different orders generate different keys (e.g., {a:1, b:2} vs {b:2, a:1}).
•Type Coercion Problems — user:123 (number) collides with user:123 (string) if not handled consistently.
•Namespace Leakage — Incomplete namespace prefixes allow cross-service collisions.

Collision Prevention Strategies:

collision-prevention.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
/**
 * Collision-resistant cache key generation.
 */
interface CacheKeyConfig {
    // All parameters that affect cached value
    params: Record<string, unknown>;
    // Type tag to prevent cross-entity collisions
    entityType: string;
    // Version to handle schema changes
    version?: number;
}
 
class CollisionResistantKey {
    /**
     * Generates a collision-resistant key with multiple safeguards.
     */
    static generate(config: CacheKeyConfig): string {
        // 1. Canonicalize parameters
        const canonicalParams = this.canonicalize(config.params);
        
        // 2. Include type tag to prevent cross-entity collisions
        const payload = {
            _type: config.entityType,
            _version: config.version ?? 1,
            ...canonicalParams,
        };
        
        // 3. Use strong hash (SHA-256)
        const hash = this.strongHash(JSON.stringify(payload));
        
        // 4. Include type in key for debuggability
        return `${config.entityType}:v${config.version ?? 1}:${hash}`;
    }
    
    /**
     * Canonicalizes object for deterministic serialization.
     * Handles nested objects, arrays, and various types.
     */
    private static canonicalize(obj: Record<string, unknown>): Record<string, unknown> {
        if (obj === null || typeof obj !== 'object') {
            return obj;
        }
        
        if (Array.isArray(obj)) {
            return obj.map(item => 
                typeof item === 'object' ? this.canonicalize(item as Record<string, unknown>) : item
            ) as unknown as Record<string, unknown>;
        }
        
        // Sort keys and recursively canonicalize
        const sortedKeys = Object.keys(obj).sort();
        const result: Record<string, unknown> = {};
        
        for (const key of sortedKeys) {
            const value = obj[key];
            
            // Normalize types
            if (value === undefined) {
                continue; // Skip undefined
            }
            
            if (typeof value === 'object' && value !== null) {
                result[key] = this.canonicalize(value as Record<string, unknown>);
            } else {
                // Convert to string to handle number/string type issues
                result[key] = String(value);
            }
        }
        
        return result;
    }
    
    private static strongHash(input: string): string {
        const crypto = require('crypto');
        return crypto
            .createHash('sha256')
            .update(input, 'utf8')
            .digest('hex')
            .substring(0, 32);
    }
}
 
// Demonstrate collision prevention
 
// These would collide with naive approaches but don't with our solution
const key1 = CollisionResistantKey.generate({
    entityType: 'product',
    params: { id: 123, category: 'electronics' },
});
 
const key2 = CollisionResistantKey.generate({
    entityType: 'product',
    params: { category: 'electronics', id: 123 }, // Different order
});
 
const key3 = CollisionResistantKey.generate({
    entityType: 'product',
    params: { id: '123', category: 'electronics' }, // String vs number
});
 
console.log(key1 === key2); // true - order doesn't matter
console.log(key1 === key3); // true - type coercion handled
 
// Different entity type prevents collision
const key4 = CollisionResistantKey.generate({
    entityType: 'order',
    params: { id: 123, category: 'electronics' },
});
 
console.log(key1 === key4); // false - different entity types

Real-World Collision Disasters

In 2020, a major e-commerce platform accidentally served personalized pricing from one user to another due to a cache key collision. The key didn't include currency conversion parameters. A user in Europe saw US prices cached for an American user. This led to pricing disputes, refunds, and regulatory scrutiny. Always audit keys for completeness.

Key Length and Performance Considerations

Cache key length directly impacts memory consumption and lookup performance. While modern caches handle long keys efficiently, understanding the tradeoffs helps optimize high-throughput systems.

Why Key Length Matters:

Key Length Impact Analysis
Factor	Short Keys (< 100 chars)	Long Keys (> 500 chars)
Memory per key	Lower baseline	Significant overhead at scale
Network transfer	Negligible	Adds latency on every operation
Hash computation	Faster	Milliseconds for very long keys
Debuggability	May be too terse	May be unwieldy in logs
Index efficiency	Better tree/hash performance	Degraded in some databases

Calculating Memory Impact:

Consider a Redis cache with 10 million keys:

key-length-analysis.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
/**
 * Memory impact analysis for cache key length.
 */
interface KeyLengthAnalysis {
    avgKeyLength: number;
    keyCount: number;
    redisOverheadPerKey: number; // Redis metadata overhead
}
 
function analyzeMemoryImpact(analysis: KeyLengthAnalysis): {
    keyMemory: number;
    totalMemory: number;
    memoryPerMillionKeys: number;
} {
    const keyMemory = analysis.avgKeyLength * analysis.keyCount;
    const overheadMemory = analysis.redisOverheadPerKey * analysis.keyCount;
    const totalMemory = keyMemory + overheadMemory;
    
    return {
        keyMemory,
        totalMemory,
        memoryPerMillionKeys: totalMemory / (analysis.keyCount / 1_000_000),
    };
}
 
// Scenario 1: Short keys
const shortKeys = analyzeMemoryImpact({
    avgKeyLength: 50,        // "prod:user:12345:profile"
    keyCount: 10_000_000,
    redisOverheadPerKey: 70, // Redis internal overhead
});
 
// Scenario 2: Long keys
const longKeys = analyzeMemoryImpact({
    avgKeyLength: 300,       // Full URL + params + hash
    keyCount: 10_000_000,
    redisOverheadPerKey: 70,
});
 
console.log("Short keys:", {
    keyMemory: `${(shortKeys.keyMemory / 1e9).toFixed(2)} GB`,
    totalMemory: `${(shortKeys.totalMemory / 1e9).toFixed(2)} GB`,
});
// keyMemory: 0.50 GB, totalMemory: 1.20 GB
 
console.log("Long keys:", {
    keyMemory: `${(longKeys.keyMemory / 1e9).toFixed(2)} GB`,
    totalMemory: `${(longKeys.totalMemory / 1e9).toFixed(2)} GB`,
});
// keyMemory: 3.00 GB, totalMemory: 3.70 GB
 
// Impact: 250 extra bytes per key = 2.5GB additional memory
// At $0.10/GB/hour in cloud, that's $2,190/year just for key overhead

Key Length Optimization Strategies:

•Hash variable components — Use a hash for long/variable parts while keeping prefixes readable
•Use abbreviations consistently — Define a mapping: product → p, category → c
•Omit obvious delimiters — p12345 instead of product:12345 (if un-ambiguous)
•Compress IDs — Use base62 encoding for numeric IDs: 12345 → 3D7
•Remove redundant prefixes — If using separate Redis databases, skip environment prefix

key-compression.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * Key compression utilities for high-volume caches.
 */
class KeyCompressor {
    // Abbreviation mapping (maintain in shared configuration)
    private static readonly abbreviations: Record<string, string> = {
        'product': 'p',
        'category': 'c',
        'user': 'u',
        'session': 's',
        'order': 'o',
        'profile': 'pf',
        'preferences': 'pr',
    };
    
    /**
     * Base62 encoding for numeric IDs.
     * Reduces "12345678" (8 chars) to "3gBa2" (5 chars).
     */
    static encodeId(id: number): string {
        const chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
        let result = '';
        let n = id;
        
        while (n > 0) {
            result = chars[n % 62] + result;
            n = Math.floor(n / 62);
        }
        
        return result || '0';
    }
    
    static decodeId(encoded: string): number {
        const chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';
        let result = 0;
        
        for (const char of encoded) {
            result = result * 62 + chars.indexOf(char);
        }
        
        return result;
    }
    
    /**
     * Compresses a key using abbreviations and ID encoding.
     */
    static compress(parts: { type: string; id?: number; aspects?: string[] }): string {
        const typeAbbrev = this.abbreviations[parts.type] || parts.type.charAt(0);
        const idEncoded = parts.id ? this.encodeId(parts.id) : '';
        const aspectsAbbrev = parts.aspects?.map(
            a => this.abbreviations[a] || a.charAt(0)
        ).join('') || '';
        
        return [typeAbbrev, idEncoded, aspectsAbbrev].filter(Boolean).join('');
    }
}
 
// Examples
const longKey = "product:12345678:profile:preferences";    // 35 characters
const shortKey = KeyCompressor.compress({
    type: 'product',
    id: 12345678,
    aspects: ['profile', 'preferences'],
});
// Result: "p3gBa2pfpr" - 10 characters (71% reduction)
 
// For 10M keys, that's ~250MB saved just on key strings

When to Optimize Key Length

Key length optimization is a micro-optimization. Prioritize correctness and debuggability first. Only compress keys when profiling shows memory pressure from key storage, or when network bandwidth is constrained. At fewer than 1 million keys, the savings rarely justify the complexity.

Versioning Strategies in Keys

Cache key versioning is essential for managing schema changes, code deployments, and data migrations. When the structure of cached data changes, old cached values become invalid—but the cache doesn't know that. Versioning solves this problem.

Why Version Cache Keys:

Versioning Use Cases

•Schema changes — Adding or removing fields from cached objects
•Serialization changes — Switching from JSON to MessagePack or Protocol Buffers
•Business logic changes — Computed values that now calculate differently
•Blue-green deployments — Old and new code versions running simultaneously
•A/B testing — Different cached representations for different experiments
•Hotfix deployments — Forcing cache refresh for bug fixes

Three Versioning Approaches:

Schema versioning includes an explicit version number in the key that changes when the data structure changes. This is ideal for planned, deliberate migrations.

schema-versioning.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
/**
 * Schema-based cache versioning.
 * Version increments when data structure changes.
 */
interface UserCacheV1 {
    id: number;
    name: string;
    email: string;
}
 
interface UserCacheV2 {
    id: number;
    name: string;
    email: string;
    phoneNumber?: string;  // New field in v2
    createdAt: Date;       // New field in v2
}
 
class UserCacheManager {
    // Increment this when UserCache structure changes
    private static readonly SCHEMA_VERSION = 2;
    
    private static keyFor(userId: number): string {
        return `user:v${this.SCHEMA_VERSION}:${userId}:profile`;
    }
    
    async getUser(userId: number): Promise<UserCacheV2 | null> {
        const key = UserCacheManager.keyFor(userId);
        const cached = await this.cache.get(key);
        
        if (cached) {
            return JSON.parse(cached) as UserCacheV2;
        }
        
        // Cache miss - fetch and cache
        const user = await this.fetchUserFromDB(userId);
        await this.cache.set(key, JSON.stringify(user), 3600);
        
        return user;
    }
}
 
// When SCHEMA_VERSION changes:
// - Old keys (user:v1:*) are orphaned (natural expiration)
// - New keys (user:v2:*) are populated with correct schema
// - No explicit cache flush required
// - Gradual migration as old entries expire

Schema Version Best Practices

Store the schema version in configuration, not code. This allows emergency version bumps without code deployments. Also consider maintaining a CHANGELOG for cache schema versions to help debugging.

Security Considerations for Cache Keys

Cache key design has significant security implications. Poorly designed keys can leak sensitive information, enable cache poisoning attacks, or allow unauthorized access to cached data.

Security Risks in Cache Keys:

Security Anti-Patterns

•PII in keys — Including emails, SSNs, or names in keys exposes them in logs and monitoring
•Predictable keys — Sequential or easily-guessed keys enable enumeration attacks
•Missing authorization — Keys that don't encode access level allow privilege escalation
•Shared keys — Same key for different users enables data leakage
•Injection vulnerabilities — User input directly in keys enables cache poisoning

secure-cache-keys.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
/**
 * Security-conscious cache key generation.
 */
class SecureCacheKey {
    /**
     * INSECURE: PII exposed in key
     */
    static insecureUserKey(email: string): string {
        // DON'T DO THIS - email visible in logs/monitoring
        return `user:email:${email}:profile`;
    }
    
    /**
     * SECURE: Use opaque identifiers
     */
    static secureUserKey(userId: string): string {
        // User ID is opaque, doesn't reveal PII
        return `user:${userId}:profile`;
    }
    
    /**
     * Include authorization context to prevent cross-user access.
     */
    static authorizedDataKey(
        userId: string,
        resourceId: string,
        permissionLevel: string
    ): string {
        // Different permission levels get different cache entries
        return `data:${resourceId}:auth:${userId}:${permissionLevel}`;
    }
    
    /**
     * Sanitize user input to prevent cache key injection.
     */
    static sanitizedKey(userInput: string): string {
        // Remove or encode dangerous characters
        const sanitized = userInput
            .replace(/[:\/\*\?]/g, '_')  // Remove control chars
            .substring(0, 100);             // Limit length
        
        return sanitized;
    }
    
    /**
     * Generate unpredictable keys for sensitive data.
     */
    static unpredictableKey(
        userId: string,
        resourceType: string,
        resourceId: string
    ): string {
        const crypto = require('crypto');
        
        // Include a secret to prevent key prediction
        const secret = process.env.CACHE_KEY_SECRET!;
        const hmac = crypto
            .createHmac('sha256', secret)
            .update(`${userId}:${resourceType}:${resourceId}`)
            .digest('hex')
            .substring(0, 16);
        
        return `${resourceType}:${resourceId}:${hmac}`;
    }
}
 
// Example: Multi-tenant cache isolation
class TenantIsolatedCache {
    constructor(private readonly tenantId: string) {}
    
    /**
     * All keys automatically scoped to tenant.
     * Even if tenant A guesses tenant B's user ID,
     * they can't access the cache entry.
     */
    key(...parts: string[]): string {
        return ['tenant', this.tenantId, ...parts].join(':');
    }
}
 
// Usage
const tenantACache = new TenantIsolatedCache('tenant-a');
const tenantBCache = new TenantIsolatedCache('tenant-b');
 
const keyA = tenantACache.key('user', '123', 'profile');
// "tenant:tenant-a:user:123:profile"
 
const keyB = tenantBCache.key('user', '123', 'profile');
// "tenant:tenant-b:user:123:profile"
 
// Same user ID "123" results in different keys - tenant isolation enforced

Cache Key Security Checklist

Before deploying cache keys to production, verify:

No PII appears in keys (check logs to confirm)
Keys include tenant/user context where needed
User input is sanitized before inclusion
Sensitive data uses unpredictable key components
Cache expiration limits exposure window

Cache Poisoning Prevention

If an attacker can control any part of a cache key, they may perform cache poisoning: storing malicious data under a predictable key. Always validate and sanitize any user-controlled input that becomes part of a cache key. Treat cache key construction with the same rigor as SQL query construction.

Summary: Cache Key Design Principles

Cache key design is foundational to building effective caching systems. Let's consolidate the essential principles:

Key Takeaways

•Effective keys balance uniqueness and minimality — Include all factors that affect cached value, but nothing more.
•Composition strategies matter — Hierarchical keys aid debugging, hash-based keys handle complexity, composite keys combine benefits.
•Namespacing prevents collisions — Service/entity/version prefixes isolate cache spaces and enable targeted invalidation.
•Collision prevention requires discipline — Canonicalize inputs, include type tags, use strong hashes, validate key uniqueness.
•Key length impacts performance — Optimize only when profiling shows memory or network pressure from key overhead.
•Versioning enables safe migrations — Schema version, deploy version, or content hash depending on use case.
•Security is non-negotiable — No PII in keys, sanitize input, include authorization context, prevent enumeration.

What's Next:

With cache key design mastered, we'll explore cache size and eviction policies in the next page. You'll learn how to determine appropriate cache sizes, implement LRU/LFU/FIFO eviction, handle memory pressure gracefully, and tune eviction parameters for different workload patterns.

Page Complete

You now understand the principles and techniques for designing effective cache keys. This foundational skill enables you to build caching systems that are correct, performant, maintainable, and secure. Apply these patterns consistently, and cache key design becomes second nature.