WAF-PERF-030 – Caching Strategy Defined & Implemented
Description
All workloads with repetitive read patterns or high-latency data sources MUST have a documented caching strategy. The strategy MUST specify cache layers, TTL policies and invalidation mechanisms. CDN MUST be configured for all public static and cacheable content. Distributed cache (Redis, Memcached) MUST be used for session data and high-frequency read-heavy lookups.
Rationale
Repeated identical database queries without caching create unnecessary load on the database server, unnecessary latency for the user, and unnecessary data transfer costs. A well-configured cache can reduce database load by 60–90%. Poor caching (wrong TTLs, missing invalidation) creates stale-data problems that are harder to debug than no caching at all.
Threat Context
| Risk | Description |
|---|---|
Database Overload |
Identical queries hundreds of times per second saturate the database server’s I/O and CPU. |
Thundering Herd |
Cache expiry of many simultaneous keys → simultaneous backend requests → database failure. |
Stale Data |
Missing cache invalidation on data mutations → users see outdated data. |
No CDN → High Latency |
Static assets served from origin without CDN → unnecessary latency for users outside the region. |
Requirement
-
Caching strategy MUST be documented (layers, TTL per data type, invalidation mechanism)
-
Distributed cache MUST be used for session data and high-frequency lookups
-
CDN MUST be configured for all public static content
-
Cache hit rates MUST be measured and monitored (target: >= 80% app cache, >= 95% CDN)
Implementation Guidance
-
Analyze access patterns: Identify top-20 database queries; measure repetition frequency
-
Create caching strategy document:
docs/caching-strategy.ymlwith layers, TTL, invalidation logic -
Deploy Redis/ElastiCache: Multi-AZ, automatic failover, encryption in transit
-
Implement cache-aside pattern: Stampede protection via lock or probabilistic early expiration
-
Configure CDN: CloudFront/Azure CDN/Cloud CDN for static assets
-
Hit rate monitoring: CloudWatch ElastiCache metrics; alert when hit rate < 70%
-
Ensure invalidation logic: Every data mutation must invalidate related cache entries
Maturity Levels
| Level | Name | Criteria |
|---|---|---|
1 |
No Cache |
All requests go to origin; no CDN; no distributed cache. |
2 |
Ad-hoc Cache |
Some things cached without strategy; arbitrary TTLs; no hit rate measurement. |
3 |
Documented Strategy |
Caching strategy document; hit rate measured; CDN active; HA Redis deployed. |
4 |
Optimized Cache |
Hit rate >= 80% achieved; automatic invalidation; stampede protection. |
5 |
Adaptive Cache |
ML-based cache warming; adaptive TTLs; intelligent edge caching. |
Terraform Checks
waf-perf-030.tf.aws.elasticache-cluster-configured
Checks: ElastiCache Replication Group must have automatic failover, multi-node and encryption.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: Use aws_elasticache_replication_group with automatic_failover_enabled = true,
num_cache_clusters >= 2, at_rest_encryption_enabled = true.
Evidence
| Type | Required | Description |
|---|---|---|
Governance |
✅ Required |
Caching strategy document with layers, TTL policies and invalidation mechanism. |
IaC |
✅ Required |
Terraform configuration for Redis/ElastiCache and CDN with cache rules. |
Config |
Optional |
Cache hit rate dashboard (target: >= 80% application cache). |
Process |
Optional |
Cache invalidation runbook for data mutations. |