WAF++ WAF++
Back to WAF++ Homepage

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

  1. Analyze access patterns: Identify top-20 database queries; measure repetition frequency

  2. Create caching strategy document: docs/caching-strategy.yml with layers, TTL, invalidation logic

  3. Deploy Redis/ElastiCache: Multi-AZ, automatic failover, encryption in transit

  4. Implement cache-aside pattern: Stampede protection via lock or probabilistic early expiration

  5. Configure CDN: CloudFront/Azure CDN/Cloud CDN for static assets

  6. Hit rate monitoring: CloudWatch ElastiCache metrics; alert when hit rate < 70%

  7. 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
resource "aws_elasticache_replication_group" "main" {
  replication_group_id       = "payment-cache"
  node_type                  = "cache.t3.medium"
  num_cache_clusters         = 2
  automatic_failover_enabled = true
  at_rest_encryption_enabled = true
  transit_encryption_enabled = true
}
resource "aws_elasticache_cluster" "main" {
  cluster_id      = "payment-cache"
  engine          = "redis"
  num_cache_nodes = 1
  # Single node, no failover
  # WAF-PERF-030 Violation
}

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.