Cached web app
ALB → three EC2 servers using ElastiCache (cache-aside) in front of RDS PostgreSQL. At 60 s Redis is flushed.
What this architecture teaches
Cache-aside is the most common caching pattern: the application checks Redis first, and only on a miss reads PostgreSQL and writes the value back.
The database only sees reads the cache misses plus every write: λ_DB = λ_read × (1 − H) + λ_write. Writes also invalidate keys, which is why the hit ratio settles below its theoretical maximum.
At 60 seconds the template flushes Redis. Every read becomes a miss at once, the database receives several times its normal load, and connections run out — a cache stampede. Recovery takes as long as the cache needs to warm up again.
What to look for
- The cold start at t = 0 is already a stampede
- Hit ratio settles near 78%: writes invalidate keys
- After the flush, misses flood RDS until the cache warms again
Components
- Web users — Web browser (Traffic source)
ALB — Application Load Balancer (Load balancer)
web-1 — Amazon EC2 (Server)- web-2 — Amazon EC2 (Server)
- web-3 — Amazon EC2 (Server)
sessions-cache — Amazon ElastiCache (Cache)
app-db — Amazon RDS (Relational DB)
Scripted events
- At 60 s: the cache is flushed