Caching Strategy for High-Traffic Apps: Redis, CDN, and Edge

Every database query you run costs you time, money, and user patience. When your app handles 10 requests per second, you can get away with hitting PostgreSQL on every page load. When you hit 1,000 requests per second, that same pattern melts your database, balloons your cloud bill, and pushes response times past the 3-second threshold where users start abandoning your app.

The fix is not "add more database replicas." The fix is to stop asking your database the same questions over and over. A well-designed caching strategy can reduce database load by 80-95%, cut p99 latency from 800ms to under 50ms, and trim your monthly infrastructure costs by 40-60%. We have seen teams cut their cloud bills in half simply by introducing proper caching at the right layers.

The problem is that most teams either cache nothing (because invalidation is "hard") or cache everything with a 5-minute TTL and pray. Both approaches fail at scale. What you need is a deliberate, layered caching architecture that matches your data access patterns, your consistency requirements, and your budget.

This guide walks you through a four-layer cache hierarchy, specific Redis patterns, CDN configuration for both static and dynamic content, edge caching with Cloudflare Workers KV, and the invalidation strategies that keep everything consistent. Every recommendation comes from production systems handling 10K+ requests per second.

Think of caching as a pyramid. Each layer is faster and smaller than the one below it. Requests travel from the top down, and the first layer that has the data wins. If no layer has it, the request reaches your database, and the response fills each cache on the way back up.

L1: In-Memory Application Cache (Microseconds)

Your application process itself is the fastest cache. An in-memory LRU (Least Recently Used) cache in Node.js, a Python dictionary, or a Go sync.Map can serve hot data in 1-5 microseconds. Zero network round trips. Zero serialization overhead.

Use L1 for data that is read thousands of times per second and changes rarely: feature flags, configuration objects, permission matrices, pricing tiers. In Node.js, libraries like lru-cache or node-cache handle this with a simple API. Set a maxSize to prevent memory leaks (typically 50-100MB, depending on your container limits) and a TTL of 30-60 seconds for automatic expiry.

The catch: L1 caches are per-process. If you run 8 instances of your API, each one has its own cache. This means L1 data can be inconsistent across instances for up to the TTL duration. For feature flags and config, that is fine. For user-specific data, it is not. That is what L2 is for.

L2: Redis / Shared Cache (Sub-Millisecond to Low Milliseconds)

Redis is your centralized, shared cache layer. All application instances read from and write to the same Redis cluster, so data is consistent across your fleet. A well-tuned Redis instance on the same VPC as your application serves reads in 0.2-0.5ms. That is 100x faster than a typical PostgreSQL query (20-50ms) and 500x faster than a cold query with joins (100-250ms).

Redis handles session data, user profiles, API responses, computed aggregations, rate limiting counters, and anything that multiple application instances need to share. We will cover specific Redis patterns in the next section.

L3: CDN Cache (Varies by POP Location)

A Content Delivery Network caches your responses at edge locations around the world. When a user in Tokyo requests your API, the CDN serves the cached response from a Tokyo POP (Point of Presence) instead of routing to your us-east-1 origin. Latency drops from 200-300ms (cross-Pacific round trip) to 5-20ms (local POP). For a deeper comparison of CDN providers, see our CDN strategy breakdown.

CDNs are not just for static assets anymore. Cloudflare, Fastly, and CloudFront all support caching dynamic API responses with fine-grained Cache-Control headers. The key is understanding which responses can be cached publicly (product listings, blog content, search results) versus which must remain private (user dashboards, account data).

L4: Edge Compute Cache (Cloudflare Workers KV, Deno Deploy)

Edge compute takes CDN caching further by running your logic at the edge. Instead of just caching static responses, you can run code that reads from a distributed key-value store (Cloudflare Workers KV, Vercel Edge Config) and constructs personalized responses without ever hitting your origin server.

A typical flow: the edge worker checks Workers KV for the user's feature flags and A/B test assignments, merges that with a cached product catalog, and returns a fully personalized page in under 10ms. Your origin server never sees the request.

Redis is the backbone of most production caching architectures, but how you use it matters as much as whether you use it. Here are the three patterns we deploy most often, with real code and real tradeoffs.

Cache-Aside (Lazy Loading)

Cache-aside is the most common pattern and the one you should start with. Your application checks Redis first. On a cache hit, it returns the data. On a cache miss, it queries the database, writes the result to Redis with a TTL, and returns the data. The application code owns the entire flow.

This pattern is simple, resilient (if Redis goes down, you fall through to the database), and only caches data that is actually requested. The downside is that the first request for any piece of data is always slow (cache miss + DB query + Redis write), and you can get stale data between updates and TTL expiry.

For a typical e-commerce product page, cache-aside with a 5-minute TTL drops average response time from 120ms to 3ms. On Black Friday traffic (50x normal), your database sees the same load it handles on a Tuesday because 99.2% of requests hit Redis.

Read-Through Cache

Read-through is similar to cache-aside, but the cache itself is responsible for loading data on a miss. You configure Redis (or a wrapper library) with a loader function, and when a key is missing, Redis calls the loader, populates itself, and returns the data. This simplifies your application code because the caching logic is centralized rather than scattered across every data access point.

Read-through works well with libraries like cacheable (Node.js) or Spring Cache (Java). The tradeoff: your cache layer now needs to understand your data sources, which adds coupling.

Write-Through and Write-Behind

Write-through updates the cache immediately when data changes. Your application writes to Redis and the database in the same operation. This eliminates stale data entirely but adds latency to writes (two writes instead of one) and requires careful error handling if one write succeeds and the other fails.

Write-behind (write-back) is the async version: write to Redis immediately, then asynchronously flush to the database in batches. This is faster for writes but risks data loss if Redis crashes before flushing. Use write-behind for analytics counters, view counts, and other data where losing a few seconds of updates is acceptable.

Which Pattern to Choose

Start with cache-aside for 90% of your data. Use write-through for data where staleness is unacceptable (inventory counts, account balances). Use write-behind for high-write, low-criticality data (page views, recently viewed items). Most production systems use all three patterns for different data types.

"There are only two hard things in computer science: cache invalidation and naming things." Phil Karlton was right, but cache invalidation is only hard if you try to make it perfect. In practice, you choose from a few well-understood strategies and accept the tradeoffs.

TTL-Based Expiry

The simplest invalidation strategy: set a time-to-live on every cached value and let it expire automatically. No coordination, no event systems, no complexity. A 60-second TTL means your data is at most 60 seconds stale. For product catalogs, blog content, search results, and most read-heavy data, that is perfectly fine.

Choosing TTL values is about matching your data's change frequency to your staleness tolerance. Here are the ranges we use in production:

• 5-15 seconds: Stock/inventory levels, live sports scores, auction prices
• 60-300 seconds: Product listings, search results, user profiles
• 3600+ seconds: Category trees, CMS content, configuration data
• 86400+ seconds: Static reference data, country lists, currency codes

Event-Driven Invalidation

When data changes, publish an event that tells caches to drop the stale entry. A product update triggers a "product.updated" event. Your cache subscriber receives it and deletes the cached product. The next read triggers a cache-aside miss and loads fresh data.

Event-driven invalidation gives you near-instant consistency without short TTLs. The implementation requires a message broker (Redis Pub/Sub, Amazon SNS, or Kafka for high throughput). The complexity is manageable: publish events from your write path, subscribe in a lightweight cache-busting service, and delete the relevant keys.

The gotcha: you need to handle message delivery failures. If an invalidation event is lost, the cache serves stale data until the TTL expires. This is why we always combine event-driven invalidation with a background TTL. Events handle the happy path (instant invalidation), and TTL handles the failure case (eventual consistency).

Version-Based Invalidation

Instead of deleting cache entries, append a version number to the cache key. When data changes, increment the version. Old cache entries become orphaned and expire naturally via TTL. This approach avoids the thundering herd problem where deleting a popular key causes thousands of simultaneous cache misses.

Example: cache key product:42:v7 becomes product:42:v8 after an update. Reads for v8 miss the cache, load from the database, and populate the new key. The old v7 entry expires on its own. This pattern is especially useful for data that changes frequently and is accessed by many concurrent users.

Most teams configure their CDN to cache static assets (images, CSS, JavaScript) and call it done. That is leaving 70% of the performance gains on the table. Modern CDNs can cache dynamic API responses, HTML pages, and even personalized content with the right Cache-Control headers.

Cache-Control Headers for APIs

The Cache-Control header is your primary tool for CDN caching. Here is how to configure it for common response types:

• Public, cacheable responses: Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=600. This tells browsers to cache for 60 seconds, CDN to cache for 5 minutes, and the CDN to serve stale content for up to 10 minutes while revalidating in the background.
• Private, user-specific responses: Cache-Control: private, max-age=0, no-store. This prevents CDN caching entirely. User dashboards, account pages, and anything with PII must use this.
• Semi-dynamic responses: Cache-Control: public, max-age=0, s-maxage=30, stale-while-revalidate=60. Browser does not cache, but the CDN caches for 30 seconds. Good for search results, trending feeds, and category pages.

Vary Headers and Cache Keys

The Vary header tells CDNs to maintain separate cache entries based on request attributes. Vary: Accept-Encoding is standard (different cache for gzip vs. brotli). Vary: Accept-Language caches per language. Be careful with Vary: Cookie because it effectively disables caching (every user has different cookies).

For personalized content, use a custom cache key instead of Vary. Cloudflare's Cache API and Fastly's VCL let you construct cache keys from specific cookie values or headers. Cache by user tier (free/pro/enterprise) rather than by individual user ID to maximize hit ratios.

Preventing Cache Stampede

Cache stampede (also called thundering herd) happens when a popular cache entry expires and hundreds of concurrent requests all miss the cache simultaneously, flooding your database. At high traffic, this can cascade into a full outage.

Three proven defenses:

• Stale-while-revalidate: Serve the expired entry while one background request refreshes the cache. All other concurrent requests get the stale (but functional) data. This is the simplest and most effective defense. Implement it via Cache-Control headers at the CDN layer and via libraries like swr or cacheable-request at the application layer.
• Lock-based recomputation: When a cache miss occurs, the first request acquires a Redis lock (SETNX with a short TTL), fetches from the database, and populates the cache. All other requests wait or get the stale value. This prevents N simultaneous database queries for the same key.
• Probabilistic early expiry: Each cache read has a small random chance of triggering a background refresh before the TTL expires. The popular XFetch algorithm uses the formula: currentTime - (TTL * beta * log(random())) to spread recomputation across time, preventing synchronized expiry across keys.

Edge caching is the newest layer in the cache hierarchy and the one with the highest impact for globally distributed applications. Instead of routing every request to your origin region, you serve data from the nearest edge location, cutting latency to single-digit milliseconds regardless of user location.

Cloudflare Workers KV in Practice

Workers KV is an eventually consistent, globally distributed key-value store. Writes propagate to 300+ edge locations within 60 seconds. Reads are local to the nearest POP, completing in under 10ms. The pricing is aggressive: $0.50 per million reads, $5 per million writes, 1GB free storage.

Best use cases for Workers KV: feature flags (write once, read millions of times), product catalog snapshots, translated content, A/B test configurations, and rate limiting rules. Poor use cases: anything requiring strong consistency (inventory, payments) or high write throughput (analytics events).

A pattern we use often: sync your product catalog to Workers KV every 5 minutes via a cron job. Your edge worker reads the catalog from KV, applies user-specific pricing rules (also stored in KV by user tier), and returns a complete product page without ever touching your origin. For a retail client, this dropped their global p95 latency from 340ms to 18ms.

Monitoring Cache Hit Ratios

You cannot optimize what you do not measure. Cache hit ratio is the single most important metric for your caching layer. Target these benchmarks:

• L1 (in-memory): 85-95% hit ratio. If it is below 85%, your working set is too large for the allocated memory or your TTLs are too short.
• L2 (Redis): 90-98% hit ratio. Below 90% indicates cache key fragmentation, overly aggressive invalidation, or missing cache population for common queries.
• L3 (CDN): 80-95% for static assets, 40-70% for dynamic content. Low CDN hit ratios usually mean incorrect Cache-Control headers or excessive Vary usage.
• L4 (Edge KV): 95%+ for read-heavy data. If you are below 95%, your sync interval might be too long or you are storing the wrong data at the edge.

Set up dashboards in Datadog, Grafana, or CloudWatch that track hit ratios per cache layer, per endpoint. Alert when ratios drop below thresholds. A sudden drop in cache hit ratio often indicates a deployment that changed cache key formats, a data model migration that introduced new query patterns, or a misconfigured TTL.

Redis itself provides excellent introspection. Run INFO stats to see keyspace_hits and keyspace_misses. Calculate your hit ratio: hits / (hits + misses) * 100. Use MEMORY USAGE to identify oversized keys. Use SLOWLOG to catch queries that take longer than expected.

Caching is not just a performance play. It is one of the most effective ways to reduce your cloud bill without sacrificing capability. Every cache hit is a database query you did not run, a compute cycle you did not burn, and a network transfer you did not pay for.

Case Study: E-Commerce Platform (50K RPM)

A mid-size e-commerce client came to us spending $4,200/month on AWS infrastructure. Their PostgreSQL RDS instance was an r6g.2xlarge ($780/month) running at 85% CPU because every product page triggered 6 database queries. Their API response times averaged 280ms, spiking to 1.2 seconds during promotions.

We implemented a three-layer caching strategy: L1 in-memory cache for category trees and navigation (60s TTL), Redis cache-aside for product data and search results (300s TTL with event-driven invalidation on product updates), and Cloudflare CDN caching for product listing pages (60s s-maxage with stale-while-revalidate).

Results after 30 days: database CPU dropped from 85% to 12%. We downgraded the RDS instance to r6g.large ($195/month). Average API latency fell from 280ms to 22ms. Monthly infrastructure cost dropped from $4,200 to $1,850, including the new Redis cluster ($180/month for ElastiCache r6g.large) and Cloudflare Pro ($20/month). That is a 56% cost reduction with a 12x latency improvement.

Case Study: SaaS Dashboard (15K RPM)

A B2B SaaS company had a reporting dashboard that aggregated data across millions of rows for each customer. Page load times averaged 4.5 seconds. Their solution was to throw bigger hardware at it: an r6g.4xlarge RDS instance ($1,560/month) and a cluster of 4 API servers ($800/month).

We precomputed dashboard aggregations nightly and cached them in Redis with 24-hour TTLs. Real-time updates used write-through caching: when new data came in, we updated the aggregation incrementally in Redis and flushed to the database asynchronously. The dashboard loaded in 200ms.

Infrastructure went from $2,360/month to $680/month. We replaced the oversized RDS instance with an r6g.large ($195/month), dropped to 2 API servers ($400/month), and added an Upstash Redis instance ($85/month). Total savings: $1,680/month, or $20,160/year.

The Cost Formula

Here is a quick way to estimate your caching ROI. Take your current database cost and multiply by your expected cache hit ratio. If Redis costs you $200/month and it offloads 90% of your database traffic, you can likely downgrade your database by 2-3 instance sizes, saving $500-$2,000/month. The break-even on a Redis cluster is almost always under 30 days.

CDN caching has an even better ROI. Cloudflare's free tier includes unlimited bandwidth. Even their Pro tier ($20/month) can eliminate thousands of dollars in origin bandwidth charges and reduce the compute needed to generate responses. For read-heavy applications, CDN caching alone can cut origin traffic by 60-80%.

If you are running a high-traffic application and your caching strategy is either nonexistent or limited to browser cache headers, you are overpaying for infrastructure and underserving your users. The patterns in this guide work at every scale, from 1,000 to 1,000,000 requests per minute. Start with cache-aside at the Redis layer, add CDN caching for your most popular endpoints, and expand from there.

Need help designing a caching architecture for your specific application? Book a free strategy call and we will audit your current setup, identify the highest-impact caching opportunities, and build a roadmap to get your latency down and your costs under control.