Cloudflare Workers KV: Edge Caching for Sub-50ms Response Times

How we reduced database queries by 90% and achieved 42ms average response times using Cloudflare Workers KV edge caching across 300+ global locations

The Problem: Database Latency Was Killing Our Performance

When we launched FIKR's multi-tenant platform, we knew performance would be critical. Our users expected fast, responsive interfaces, and search engines increasingly factor page speed into rankings. We had already implemented Edge SSR with Cloudflare Workers to serve server-rendered HTML to bots, and that worked brilliantly for SEO. But we had a significant bottleneck that kept showing up in our metrics: database latency.

Our Supabase PostgreSQL instance runs in AWS us-east-1 on the East Coast of the United States. That location works great for users in North America. Requests from New York or Boston hit our database with 5-10ms latency. But requests from Europe added 80-100ms of latency just to cross the Atlantic. Asian traffic was even worse, with 150-200ms delays. For a user in Singapore requesting their dashboard data, more than 60% of their total page load time was spent waiting for database queries to return.

We were doing everything else right. Our edge workers rendered HTML in under 10ms. Our React components were optimized. Our bundles were small and efficiently loaded. But none of that mattered when every page request required multiple round trips to a database on the other side of the world. Users in Europe and Asia were experiencing noticeably slower performance than users in North America, and that wasn't acceptable.

The obvious solution was caching, but traditional caching approaches had serious limitations. We could add Redis or Memcached in front of our database, but that would just be another centralized service in us-east-1. Users in Singapore would still be making 150ms round trips, just to a cache instead of the database. We could deploy Redis instances in multiple regions, but then we'd need to manage synchronization, handle cache invalidation across regions, and deal with the operational complexity of running distributed infrastructure.

Then we realized we already had the perfect caching layer available: Cloudflare Workers KV. It's a globally distributed key-value store that runs at every edge location, with automatic replication and sub-10ms read latency worldwide. We were already using Workers for edge rendering, so adding KV caching would be a natural extension of our existing architecture.

Understanding Workers KV Architecture

Workers KV is fundamentally different from traditional caching solutions like Redis or Memcached. Instead of being a centralized service that you deploy and manage, KV is a globally distributed key-value store that Cloudflare operates across their entire edge network. When you write a key-value pair to KV, Cloudflare automatically replicates that data to all 300+ edge locations around the world. When you read from KV, the data comes from the edge location closest to where your Worker is running.

The architecture is designed for eventual consistency with fast reads. Writes are accepted immediately and then propagated to edge locations over the next 60 seconds. This means there's a brief window where different edge locations might have slightly different data, but for most caching use cases, that trade-off is completely acceptable. Read latency is typically under 1 millisecond at the edge, which is 50-100 times faster than querying a centralized database or cache.

Here's what happens when a user requests a page that uses KV caching:

1. Request arrives at nearest Cloudflare edge location (typically <5ms from user)
2. Edge Worker checks if required data exists in local KV store (<1ms read)
3. If cache hit: Worker renders response immediately using cached data (total: <15ms)
4. If cache miss: Worker queries Supabase database (80-150ms depending on region)
5. Worker stores result in KV with appropriate TTL (expires after configured time)
6. Next request for same data hits cache at every edge location (propagation: 60 seconds)

The performance improvement is dramatic. A user in Singapore requesting their organization's data used to wait 180ms for the database query. Now they wait less than 1ms for the KV read. That's a 180x speedup. A user in London goes from 90ms to under 1ms, a 90x improvement. Even users in New York benefit because reading from local KV is faster than querying a database in the same region.

But the real power comes from the scale. KV isn't just fast for one user or one piece of data. It's fast for millions of users accessing thousands of different cached entries, all served from the edge with the same sub-millisecond latency. And because Cloudflare handles all the replication and distribution, we don't need to think about it.

Why We Didn't Choose Redis or Memcached

Redis is fantastic, and we want to be clear about that upfront. It's the gold standard for caching, with incredibly fast performance, rich data structures, and battle-tested reliability. Memcached is similarly excellent for pure key-value caching. Both have massive communities, extensive documentation, and proven track records at enterprise scale. If we needed complex caching operations, atomic counters, or pub-sub messaging, Redis would absolutely be the right choice.

But for our specific use case, Redis and Memcached presented significant challenges. The fundamental issue is geography. Both are centralized services that you deploy in specific regions. If we deployed Redis in us-east-1 alongside our database, users in Asia would still experience 150ms latency just to read from cache. That defeats much of the purpose of caching in the first place.

Here are the key factors that made us hesitant about traditional caching:

• Geographic Limitations: Single-region deployment means cache is far from most users
• Multi-Region Complexity: Running Redis in multiple regions requires custom replication logic
• Infrastructure Costs: ElastiCache starts at $15/month per instance, need 3-5 regions minimum
• Operational Overhead: Managing instances, monitoring memory, handling failover
• Network Latency: Even in-region Redis adds 3-8ms compared to <1ms for KV

Workers KV solved all these problems in one package. It's automatically global, so every user gets low latency regardless of location. There's no infrastructure to manage because Cloudflare handles all the distribution and replication. And the pricing model is incredibly simple: $5 per month includes 10 million reads, which is more than enough for most applications.

The Economics of Edge Caching

One of the most compelling aspects of Workers KV is the economics. Cloudflare's pricing is straightforward and generous: the Workers Paid plan ($5/month) includes 1 GB of stored data and 10 million read operations per month. Write operations are included up to 1 million per month. Additional reads cost $0.50 per million, and additional writes cost $5 per million.

Let's break down what you get for $5/month:

• 1 GB storage: Enough for hundreds of thousands of cached entries
• 10M reads/month: Approximately 330,000 cache reads per day
• 1M writes/month: Approximately 33,000 cache writes per day
• 300+ edge locations: Global distribution included automatically
• Sub-1ms read latency: At every location, for every request

Compare this to running a globally distributed Redis setup. You'd want Redis instances in at least five key regions to provide good coverage: US East, US West, Europe, Asia Pacific, and South America. Using AWS ElastiCache, even the smallest cache.t3.micro instances cost $15 per month each. That's $75 per month just for the cache instances, not including data transfer costs between regions or the custom replication logic you'd need to build.

But the cost comparison gets even more dramatic at scale. With Workers KV, as your traffic grows, the cost grows slowly and predictably. Going from 10 million reads to 50 million reads adds just $20 per month ($0.50 per additional million). With Redis, scaling to handle 5x more traffic might require upgrading to larger instances in each region, potentially pushing costs to $300-500 per month or more.

For our platform with about 8 million KV reads per month, we pay exactly $5. That same traffic handled by a multi-region Redis deployment would cost approximately $100-150 per month, not including the engineering time to build and maintain the replication logic. The savings are substantial: roughly $1,140-1,740 per year, or about 90-95% cost reduction.

Implementation: Caching Strategy

Implementing KV caching required careful thinking about what to cache and for how long. Not all data is equally cacheable. Some data changes frequently and needs to be fresh. Other data changes rarely and can be cached aggressively. We developed a tiered caching strategy based on how often data changes and how critical freshness is to the user experience.

Our caching tiers are structured by data volatility and business impact:

• Tier 1 - Organization Profiles: TTL 6 hours (rarely change, high read volume)
• Tier 2 - Blog Content: TTL 30 minutes (occasional updates, medium freshness needs)
• Tier 3 - User Sessions: TTL 15 minutes (moderate change rate, needs reasonable freshness)
• Tier 4 - Dashboard Metrics: TTL 5 minutes (frequent updates, freshness matters)
• No Cache - Real-time Data: Live chat, notifications, financial transactions

The implementation in our Worker is straightforward but powerful. We created a caching utility that handles all the KV operations with automatic fallback to the database if the cache misses.

Core Caching Function:

async function getCachedData(key, ttlSeconds, fetchFn) {
  // Try to read from KV cache
  const cached = await CACHE_KV.get(key, { type: 'json' });

  if (cached) {
    return cached;
  }

  // Cache miss - fetch from database
  const fresh = await fetchFn();

  // Store in KV with expiration
  await CACHE_KV.put(
    key,
    JSON.stringify(fresh),
    { expirationTtl: ttlSeconds }
  );

  return fresh;
}

// Usage example
const orgData = await getCachedData(
  `org:${orgId}`,
  21600, // 6 hours
  () => supabase.from('organizations').select('*').eq('id', orgId).single()
);

This pattern gives us cache-aside semantics: check the cache first, and only query the database on a miss. The TTL (time-to-live) is baked into the KV entry, so expired entries are automatically removed by Cloudflare. We don't need to implement any cache eviction logic ourselves.

Smart Cache Invalidation:

async function invalidateCache(pattern) {
  // KV doesn't support pattern deletion, so we maintain a key registry
  const keys = await CACHE_KV.get(`registry:${pattern}`, { type: 'json' }) || [];

  // Delete all keys matching pattern
  await Promise.all(
    keys.map(key => CACHE_KV.delete(key))
  );

  // Clear the registry
  await CACHE_KV.delete(`registry:${pattern}`);
}

// When organization updates their profile
await supabase.from('organizations').update(data).eq('id', orgId);
await invalidateCache(`org:${orgId}`); // Clear cache immediately

This invalidation strategy ensures users see fresh data when they make changes. When an organization updates their profile, we immediately invalidate the cache entry. The next request will fetch fresh data from the database and populate the cache with the updated information.

Implementation: Batch Operations and Prefetching

One of the most powerful patterns we discovered was using KV for batch operations. Many of our pages need to load multiple related pieces of data. For example, a dashboard might need organization data, user preferences, recent activity, and notification counts. Without caching, that's four separate database queries, potentially taking 300-400ms total for a user in Europe.

With KV, we can fetch all four pieces of data in parallel from the edge in under 5ms total. The implementation uses Promise.all to fetch multiple KV entries simultaneously.

Parallel Cache Reads:

async function getDashboardData(orgId, userId) {
  const [org, preferences, activity, notifications] = await Promise.all([
    getCachedData(`org:${orgId}`, 21600, () => fetchOrg(orgId)),
    getCachedData(`prefs:${userId}`, 3600, () => fetchPreferences(userId)),
    getCachedData(`activity:${orgId}`, 300, () => fetchActivity(orgId)),
    getCachedData(`notifications:${userId}`, 60, () => fetchNotifications(userId))
  ]);

  return { org, preferences, activity, notifications };
}

This pattern is dramatically faster than sequential database queries and even faster than parallel database queries, because all the data is already at the edge. A European user requesting their dashboard goes from 320ms (4 queries at 80ms each) to under 5ms (4 KV reads in parallel).

We also implemented smart prefetching for common navigation patterns. When a user loads their organization's homepage, we know they're likely to navigate to their dashboard next. So we prefetch dashboard data into KV while the homepage is loading. By the time they click to the dashboard, the data is already cached at their edge location.

Real Results After 60 Days

The impact of implementing Workers KV was immediate and measurable. We had already achieved good performance with Edge SSR, but database latency was still our biggest bottleneck. After deploying KV caching with our tiered strategy, the performance transformation was dramatic.

Our monitoring showed the results clearly:

Before Workers KV:

• Average response time (US users): 85ms
• Average response time (Europe): 165ms
• Average response time (Asia): 230ms
• Database queries: ~400,000 per day
• 95th percentile response: 320ms

After Workers KV (60 days):

• Average response time (US users): 38ms
• Average response time (Europe): 42ms
• Average response time (Asia): 45ms
• Database queries: ~40,000 per day (90% reduction)
• 95th percentile response: 68ms
• Cache hit rate: 91.3%
• Infrastructure cost: $5/month

The response time improvements are transformative. Users in Asia went from 230ms average to 45ms, a 5x speedup. European users improved from 165ms to 42ms, nearly 4x faster. Even US users, who already had relatively good performance, saw a 2x improvement. And critically, performance is now consistent globally. The difference between our fastest and slowest regions is just 7ms instead of 145ms.

The database load reduction was equally impressive. By caching aggressively with appropriate TTLs, we reduced database queries by 90%. Our Supabase instance went from handling 400,000 queries per day to just 40,000. This has huge implications for scaling. We can handle 10x more traffic without upgrading our database tier, and when we do need to scale the database, we'll scale it 10x slower than we would without caching.

The cost for all this performance and scale? Still just $5 per month. We're using about 320 MB of KV storage and 8 million reads per month, both well within the included limits of the Workers Paid plan.

Challenges We Had to Overcome

Implementing Workers KV wasn't completely smooth sailing. We ran into several challenges that required careful thinking and sometimes creative solutions.

The first challenge was the eventual consistency model. When you write data to KV, it takes up to 60 seconds to propagate to all edge locations. This creates a potential consistency problem: if a user updates their profile on one edge location, they might see stale data if their next request routes to a different edge location that hasn't received the update yet.

We addressed this through a combination of strategies:

• Immediate invalidation on writes (delete cache key when data changes)
• Sticky routing for users (same user typically hits same edge location)
• Short TTLs for user-modified data (5-15 minutes vs 6 hours for static data)
• Client-side optimistic updates (show change immediately in UI)
• Result: Users perceive instant updates, actual propagation lag is invisible

The second challenge was KV's lack of atomic operations and complex data structures. Redis supports atomic counters, sorted sets, and atomic list operations. KV is strictly key-value with no atomic operations beyond single-key reads and writes. This meant we couldn't use KV for some use cases where we needed true atomic behavior, like rate limiting or real-time analytics.

Our solution was using the right tool for each job:

• Workers KV: User profiles, content, relatively static data
• Durable Objects: Rate limiting, real-time counters, stateful operations
• Database: Transactional data, complex queries, source of truth
• Result: Each system handles what it's best at, no compromises

The third challenge was debugging and observability. When cache-related issues occur, it can be hard to understand what's happening. Is the cache hit or miss? Is the data stale? Is there a replication delay? Traditional debugging tools don't work well with edge systems distributed across 300 locations.

We built custom observability into our caching layer:

• Every response includes cache status headers (HIT, MISS, STALE)
• Cache key and TTL logged for debugging (visible in Worker logs)
• Custom analytics tracking cache hit rates by region and data type
• Test endpoints that force cache misses for debugging
• Result: Full visibility into cache behavior, easy debugging

Best Practices for Cache Invalidation

Cache invalidation is famously one of the two hard problems in computer science, and working with KV's eventual consistency model makes it even more interesting. We developed a set of best practices through trial and error that help ensure users see fresh data when they need to.

The fundamental principle is to be aggressive about invalidation on writes but conservative about cache TTLs. When data changes, immediately delete the cache entry. Don't try to update it in place, just delete it and let the next read fetch fresh data from the database. This ensures the next user who requests that data will get the current version, even if it means a slightly slower request.

Our invalidation patterns:

• User Actions: Invalidate immediately when user changes data they can see
• Admin Actions: Invalidate with 5-minute delay for data that affects multiple users
• Scheduled Updates: Let TTL expire naturally for data updated on schedule
• Bulk Changes: Use registry pattern to invalidate multiple related keys

For complex invalidation scenarios, we maintain a key registry in KV. When we cache a piece of data, we also add its key to a registry entry. When we need to invalidate all data related to an organization, we can look up all keys in that organization's registry and delete them in one batch operation.

The other critical practice is using appropriate TTLs for different data types. Static content like blog posts can have long TTLs (30 minutes or more). User-specific data needs shorter TTLs (5-15 minutes). Real-time data shouldn't be cached at all. Matching the TTL to the data volatility ensures users see fresh data without sacrificing cache effectiveness.

When Workers KV Makes Sense vs Redis

Workers KV is not a universal replacement for traditional caching solutions. There are specific scenarios where it excels and others where Redis or Memcached would be better choices. Being honest about these trade-offs helps you make the right decision for your specific needs.

Choose Workers KV if:

• You need globally distributed caching with low latency everywhere
• Your data access pattern is heavily read-focused (90%+ reads)
• You can tolerate 60-second eventual consistency for writes
• You're already using Cloudflare Workers or Pages
• You want minimal infrastructure management and costs
• Your cache needs are relatively simple key-value operations

Choose Redis/Memcached if:

• You need strong consistency or atomic operations
• You have complex caching needs (sorted sets, pub-sub, transactions)
• Most of your traffic comes from a single geographic region
• You need cache invalidation patterns like key scanning or pattern matching
• You have heavy write workloads (more than 20% writes)
• You're already invested in AWS/Azure/GCP infrastructure

Final Thoughts

Implementing Workers KV transformed our application's performance globally. We went from wildly varying response times based on user location (85ms to 230ms) to consistently fast performance everywhere (38-45ms). We reduced our database load by 90%, which has massive implications for scaling and cost management. And we did all of this for $5 per month with zero additional infrastructure to manage.

The best part is how it compounds with our other edge technologies. We were already using Workers for Edge SSR, so adding KV caching was a natural extension. The two work together perfectly: Edge SSR renders HTML fast at the edge, and KV provides the data for that rendering with sub-millisecond latency. The combination gives us Next.js-level performance at a fraction of the cost and complexity.

Implementation took about five days from initial prototype to production deployment. The first two days were spent understanding KV's consistency model and designing our caching strategy. The next two days were implementation and testing. The final day was optimizing cache hit rates and building observability tools. Most of the complexity was in getting the caching strategy right, not in the actual KV integration.

If you're building a global application and struggling with database latency, Workers KV is absolutely worth evaluating. It's not right for every use case, but for read-heavy workloads with reasonable consistency requirements, it's incredibly effective. The combination of global distribution, sub-millisecond reads, and minimal cost is hard to beat.