Cloudflare Workers Are Eating Lambda's Lunch for Latency-Sensitive Apps

We built a critical user authentication service, central to every API request our product handled. Initially, we ran it on AWS Lambda, our default serverless choice, and it consistently delivered 150ms P99 latency for global users. Switching to Cloudflare Workers not only slashed that to a predictable 30ms, it also cut our infrastructure bill by 90%.

Why this matters in 2026

User expectations for instant feedback have never been higher. A few hundred milliseconds of latency can mean the difference between a user staying engaged or abandoning your application. As companies expand globally and real-time features, from AI inference at the edge to personalized content delivery, become standard, the geographical distance between your users and your compute resources is a critical performance bottleneck. Traditional cloud regions, while powerful, simply cannot compete with compute distributed across hundreds of cities worldwide.

Three things I learned shipping this in production

1. Latency isn't just about network hops, it's about cold starts and execution environment.

We ran a marketing analytics ingestion service, collecting millions of events daily from client-side SDKs. Our initial architecture used AWS Lambda@Edge, which promises execution closer to users. We thought this was the answer to our latency problems. We were wrong.

Even with Lambda@Edge, our P99 latency for the POST /event endpoint hovered around 800ms. This meant real-time dashboards for our customers updated with unacceptable delays, often showing stale data for several seconds. The issue wasn't just network latency, it was the fundamental execution model. Lambda, even at the edge, relies on container startup times. While AWS has made strides, a container still needs to spin up, load the runtime, and initialize your code. This "cold start" overhead, though mitigated for frequently invoked functions, still hit us hard during traffic spikes or for less frequently called event types. We used the Node.js 16.x runtime, which is generally fast, but the underlying container model was the bottleneck.

Cloudflare Workers operate on a different principle entirely: V8 isolates. Instead of containers, Workers run in lightweight JavaScript V8 isolates, the same technology that powers Chrome. These isolates are persistent and can handle multiple requests concurrently, meaning true near-zero cold starts. When we migrated our analytics ingestion to Cloudflare Workers, using their JavaScript runtime, our P99 latency dropped to a consistent 70ms. This 730ms improvement was a game-changer for our real-time dashboards. The Worker simply processed the incoming JSON payload and queued it for downstream processing.

Here's a simplified version of the Worker code we used for event ingestion:

// src/worker.js
export default {
  async fetch(request, env, ctx) {
    if (request.method !== 'POST') {
      return new Response('Method Not Allowed', { status: 405 });
    }
    try {
      const eventData = await request.json();
      // In production, we'd add validation and more robust error handling.
      // For this example, we log and send to a Cloudflare Queue.
      console.log('Received event:', eventData);
      // Use ctx.waitUntil to ensure the queue send completes
      // even if the HTTP response is sent immediately.
      ctx.waitUntil(env.ANALYTICS_QUEUE.send(eventData)); // ANALYTICS_QUEUE is a bound Cloudflare Queue
      return new Response('Event received and queued', { status: 202 });
    } catch (error) {
      console.error('Error processing event:', error);
      return new Response('Bad Request: ' + error.message, { status: 400 });
    }
  },
};

This Worker, deployed globally, took less than 50ms to execute, with the remaining latency being network round trip. The key was that the V8 isolate was always ready, eliminating the cold start penalty that plagued our Lambda@Edge setup.

2. Cost models are wildly different, and Lambda can break the bank for high-volume, low-compute tasks.

At a previous startup, we had a simple API gateway for a mobile application. This gateway's primary job was to route requests, perform basic JWT validation, and occasionally fetch a user profile from a cache. Every single API call, even a GET /health endpoint, went through an AWS API Gateway integration with a Lambda function. We had millions of requests per day, mostly very small, quick operations.

Our Lambda bill for this gateway alone escalated to over $3,000 per month. We were using Python 3.9 Lambda functions, configured with 256MB of memory to mitigate cold starts as much as possible, even though the actual compute required was minimal, likely less than 20MB. AWS Lambda charges based on the number of invocations and the duration of execution, rounded up to the nearest millisecond, multiplied by the allocated memory. For millions of tiny requests, this model becomes incredibly expensive. Each invocation, no matter how short, incurs a base cost. The 256MB minimum memory allocation meant we were paying for compute we simply weren't using.

When we rebuilt a similar service using Cloudflare Workers for another product, the cost difference was staggering. Cloudflare Workers have an extremely generous free tier (100,000 requests per day) and then charge a flat rate per million requests (typically $0.15/million for standard usage) plus a very small duration charge. For the same volume of traffic, performing similar routing and authentication tasks, our Cloudflare Workers bill rarely exceeded $50 per month. This was a 98% reduction in cost for an identical, if not superior, performance profile.

The difference lies in the unit of billing. Lambda's model is optimized for longer-running, bursty tasks where you might need significant compute for a short period. Workers are optimized for extremely short, high-volume HTTP requests. For an API gateway or any request-path logic, where your function might only run for a few milliseconds, the overhead of Lambda's invocation model adds up fast. With Workers, that minimal execution time and the incredibly low per-invocation cost make them unbeatable for scale.

3. Developer experience and integrated tooling can make or break velocity.

Deploying changes to critical infrastructure needs to be fast and reliable. When we managed our authentication middleware on Lambda, deployments were a multi-step process. We used Serverless Framework version 3.x, which abstracted away much of the underlying AWS CloudFormation. Even so, a typical deployment involved: packaging the code, uploading it to S3, updating CloudFormation stacks, waiting for IAM roles to propagate, and finally, updating the Lambda function itself. This process often took between two to five minutes for a minor code change. For critical bug fixes or rapid feature iteration, this was a significant drag on developer velocity. We even hit CloudFormation deployment limits on occasion, forcing us to wait before deploying further changes.

Cloudflare Workers, with their wrangler CLI (version 3.x), offered a dramatically different experience. A simple wrangler deploy command takes your code, bundles it, and pushes it to Cloudflare's network. The entire process, from hitting enter to the code being live globally, typically takes less than 10 seconds. This is because Workers are deployed as byte code to Cloudflare's global network of edge servers, not as containers that need to be provisioned in specific regions. There's no CloudFormation to update, no S3 buckets to manage, no IAM roles to configure for each deployment. It's a single, fast operation.

Beyond deployment, the local development story is equally compelling. wrangler dev provides a local server that accurately simulates the Cloudflare Workers environment, including bindings to KV stores, Durable Objects, R2 storage, and Queues. This means you can develop and test your Worker locally with high fidelity, catching integration issues before they even touch a staging environment. With Lambda, local testing often involves mocks or containerized environments that don't fully replicate the distributed nature of the service or the latency associated with actual cloud resource interactions. This immediate feedback loop from wrangler dev significantly accelerated our development cycles, allowing us to iterate on new features and address issues with unprecedented speed. We shipped more features faster, with fewer surprises in production.

What I would do differently if I started today

If I were starting a new project today