Caching and CDN Basics
Learn how caches and CDNs reduce repeated work, improve latency, protect origins, and introduce freshness and invalidation trade-offs.
What you will be able to do
A cache stores a faster copy of data so the system does not repeat expensive work. A CDN is a geographically distributed cache, usually for static assets and cacheable web/API content near users.
Why Cache?
Caching can reduce latency, database load, compute cost, and origin traffic. But every cache introduces a freshness question: when is the copy allowed to be stale, and how will it be updated or invalidated?
| Cache layer | Good for | Risk |
|---|---|---|
| Browser cache | Static assets and user-local reuse | Hard to invalidate immediately. |
| CDN/edge cache | Images, scripts, public pages, some API responses | Stale public content or accidental private caching. |
| Application cache | Hot database results and expensive computed data | Invalidation and memory pressure. |
| Database cache/buffer | Internal database performance | Not a product-level caching strategy. |
| Materialized view | Precomputed summaries | Freshness and update correctness. |
Scenario: Course Homepage
A course homepage has cover images, course metadata, lesson lists, learner-specific progress, and recommendations. These pieces should not all have the same caching rule.
| Data | Cache decision | Reason |
|---|---|---|
| Cover images | CDN with long TTL | Static and shared by many users. |
| Published course metadata | CDN/app cache with moderate TTL | Changes infrequently. |
| Lesson list | Cache until publish event invalidates | Mostly stable, but must update after content release. |
| Learner progress | Short cache or no shared CDN cache | User-specific and should stay reasonably fresh. |
| Recommendations | Can be cached per user for minutes | Personalized but not strictly correct. |
Cache-Aside and TTL
In cache-aside, the application checks the cache first. On a miss, it reads from the source of truth, stores the result in cache, then returns it. TTL decides how long cached data may live.
| Concept | Meaning | Example |
|---|---|---|
| Cache hit | Data found in cache | Return course metadata from Redis. |
| Cache miss | Data not found in cache | Read database and populate cache. |
| TTL | Time before entry expires | Course metadata expires after 10 minutes. |
| Invalidation | Remove/update stale cache entry | Purge lesson list after publishing new lesson. |
| Stale-while-revalidate | Serve stale copy while refreshing | Fast course page while background refreshes content. |
Design principle
Cache data that is expensive to fetch or compute, read often, and safe to be stale for a clearly defined time.
Hot Keys and Stampedes
A hot key receives extreme traffic for one cached item. A cache stampede happens when many requests miss or expire at once and all hit the origin together.
| Problem | Symptom | Mitigation |
|---|---|---|
| Hot key | One course/product/news item gets huge traffic | Replicate cache, local cache, request coalescing, edge cache. |
| Stampede | Origin spikes when cache expires | Jitter TTLs, lock/coalesce refreshes, stale-while-revalidate. |
| Stale sensitive data | User sees incorrect balance/progress | Short TTL, event invalidation, or avoid caching critical value. |
| Private data leak | One user's data served to another | Correct cache keys and avoid shared CDN for private responses. |
Cloud Caching and CDN
| Need | AWS | GCP | Azure |
|---|---|---|---|
| CDN | CloudFront | Cloud CDN | Azure Front Door/CDN |
| Managed Redis/Memcached | ElastiCache | Memorystore | Azure Cache for Redis |
| Object origin | S3 | Cloud Storage | Blob Storage |
| Edge security | WAF/Shield | Cloud Armor | WAF/DDoS Protection |
| Invalidation/purge | CloudFront invalidations | Cloud CDN invalidation | Azure CDN/Front Door purge |
Cache Review Checklist
- What exact data is cached?
- Who is allowed to see it?
- What is the source of truth?
- How stale may it be?
- How is it invalidated or refreshed?
- What happens if the cache is empty or down?
- Can one key become hot?
Beginner Mistakes
- Caching before knowing the slow query or expensive operation.
- Caching private user data in a shared CDN.
- Forgetting invalidation and serving stale product-critical data.
- Using the cache as the only source of truth.
- Setting identical TTLs that cause synchronized cache stampedes.
Guided Practice
Practice task
For a product detail page, decide caching rules for product image, product title, inventory count, reviews summary, and personalized discount.
Sample Answer
| Data | Caching rule |
|---|---|
| Product image | CDN long TTL with versioned URL. |
| Product title/description | CDN or app cache with invalidation on catalog update. |
| Inventory count | Short TTL or no cache if scarce and checkout-critical. |
| Reviews summary | Cache for minutes; update asynchronously. |
| Personalized discount | Private cache only or compute on request; do not share through public CDN. |
Module 4 Wrap-Up
You now understand the first scalability toolkit: scale the bottleneck, distribute traffic with load balancers, keep services stateless, and cache safe repeated reads.
Before You Continue
- You should know vertical and horizontal scaling trade-offs.
- You should understand load balancer responsibilities.
- You should recognize why stateless services are easier to scale.
- You should know caching and CDN freshness risks.
- You are ready for distributed data: replication, partitioning, consistency models, and conflicts.