Serverless is a cloud computing execution model in which the cloud provider dynamically manages the allocation and provisioning of servers, developers write and deploy code without configuring, managing, or maintaining the underlying server infrastructure. The name is somewhat misleading, servers absolutely exist and run serverless code, but from the developer’s perspective the servers are invisible. The developer writes a function, deploys it to the serverless platform, and the platform handles everything else, provisioning compute capacity, scaling up under load, scaling down during quiet periods, applying security patches, and managing availability.

The serverless model represents a fundamental shift in how developers think about deploying code. Traditional web application deployment requires provisioning servers, choosing an instance size, installing an operating system, configuring web server software, deploying application code, managing security updates, monitoring server health, and scaling manually or through configured auto-scaling rules. Serverless eliminates all of this infrastructure management, the developer’s responsibility ends at the function boundary. Everything below the function, hardware, operating system, runtime environment, scaling, is the cloud provider’s responsibility.

Serverless functions are event-driven, they execute in response to specific triggers rather than running continuously. An HTTP request trigger fires the function when a web request arrives. A database change trigger fires the function when data is modified. A scheduled trigger fires the function at configured time intervals. The function executes, produces a result, and terminates, the compute capacity is deallocated when the function completes. The developer pays only for the compute consumed during execution, not for idle server time between requests.

For redirect management serverless is the enabling architecture for many modern redirect platforms, functions that receive HTTP requests, look up redirect rules, and return redirect responses scale automatically to handle any traffic volume without infrastructure management. Understanding serverless clarifies how redirect management platforms achieve elastic scalability without requiring dedicated server fleets.

Serverless vs traditional hosting

The distinction between serverless and traditional hosting models clarifies what serverless changes and why it matters for web infrastructure.

Traditional hosting, always-on servers: traditional web hosting runs application code on continuously running servers. A Virtual Private Server, VPS, or dedicated server runs an operating system, a web server like Nginx or Apache, and an application server like Node.js or PHP continuously, regardless of whether requests are arriving. The server costs the same whether handling 1,000 requests per minute or 0 requests per minute. Scaling requires provisioning additional servers, a time-consuming manual or semi-automated process.

Traditional hosting provides predictable performance, the server is always ready to handle requests without cold start delays, but requires infrastructure management and charges for idle capacity. It is well-suited for applications with consistent, predictable traffic that justifies dedicated server capacity.

Container-based hosting, managed but persistent: container platforms, Kubernetes, AWS ECS, Google Cloud Run, provide more flexibility than traditional VPS hosting while still requiring container orchestration management. Containers can scale more quickly than traditional servers, adding container instances in seconds rather than minutes, but the container orchestration infrastructure itself requires management. Containers are typically long-running processes rather than per-request execution contexts.

Serverless, on-demand execution: serverless functions execute only when triggered, the compute capacity is allocated at request time and deallocated after the function completes. No idle costs. Scaling is automatic, the platform spins up additional function instances to handle increasing request volumes without human intervention. Scaling down is equally automatic, idle instances are terminated when request volumes decrease.

This on-demand model is cost-efficient for variable traffic, applications with uneven traffic patterns pay only for actual compute usage rather than reserving capacity for peak load. It also eliminates operational overhead, no server patching, no capacity planning, no availability monitoring at the infrastructure level.

Serverless execution models

Different serverless platforms use different execution models, the choice of model affects performance characteristics, capability limitations, and appropriate use cases.

Container-based serverless, AWS Lambda, Google Cloud Functions: traditional serverless functions execute in lightweight containers. The platform maintains a pool of containers, some warm and ready, others cold and requiring initialisation. A cold start, the initialisation of a new container instance, takes hundreds of milliseconds for container-based serverless. The cold start includes container creation, runtime initialisation, starting Node.js, Python, or other runtime, and function code loading. For latency-sensitive applications cold starts are a significant concern.

After the initial cold start the container remains warm, subsequent requests to the same instance execute without cold start overhead. The platform reuses warm containers for incoming requests, a warm instance responds in milliseconds. However if a request arrives when no warm instance is available, during traffic spikes or after idle periods, a cold start is unavoidable.

Isolate-based serverless, Cloudflare Workers, Deno Deploy: modern edge serverless platforms use V8 isolates or WebAssembly sandboxes rather than containers. Isolate creation is orders of magnitude faster than container creation, microseconds rather than hundreds of milliseconds. The runtime, V8, is already running on the edge node, creating a new isolate is simply allocating a new execution context within the running V8 process.

Isolate-based serverless effectively eliminates cold starts as a user-visible concern, sub-millisecond isolate creation means every request starts fresh without perceptible initialisation overhead. This makes isolate-based serverless practical for latency-sensitive applications where container-based serverless cold starts are problematic.

WebAssembly-based serverless, Fastly Compute@Edge: some edge serverless platforms use WebAssembly as the execution format rather than JavaScript in V8. WebAssembly provides near-native execution speed and supports multiple source languages, Rust, Go, C++, and others compile to WebAssembly. WebAssembly cold starts are fast, typically under a millisecond, making WebAssembly-based serverless competitive with isolate-based approaches.

Serverless function characteristics

Serverless functions have specific characteristics that distinguish them from traditional long-running application servers, understanding these characteristics is important for designing serverless-based redirect infrastructure.

Statelessness: serverless functions are stateless by design. Each function invocation starts with no memory of previous invocations, no in-memory state persists between requests. A redirect rule cached in memory during one function execution is not available to the next execution, which may run on a different function instance. Statelessness requires explicit state management, redirect rules and other persistent data must be stored in external data stores, KV stores, databases, rather than in function memory.

This statelessness is a feature as much as a constraint, stateless functions can be scaled horizontally without concerns about state synchronisation across instances. Multiple simultaneous function executions handle requests independently, no coordination required.

Ephemeral execution contexts: function instances are created for requests and discarded after completion or idle timeout. Compute resources are not reserved between requests. Variables, connections, and cached data from one invocation are not guaranteed to be available in subsequent invocations, even from the same function instance.

Some serverless platforms reuse warm instances, a function instance that handled one request may handle subsequent requests, providing some execution context persistence between requests to the same warm instance. But this reuse is not guaranteed, developers must not rely on it for correctness. Ephemeral contexts enforce clean separation between requests, a desirable property for multi-tenant infrastructure handling many customers’ redirect rules.

Execution time limits: serverless functions have maximum execution time limits, ranging from seconds to minutes depending on the platform. AWS Lambda maximum execution time is 15 minutes. Cloudflare Workers maximum CPU time is 30 seconds on the paid plan. Executions exceeding the limit are terminated. For redirect management, which requires only milliseconds of execution time, these limits are never a constraint. They matter for long-running data processing tasks that are not appropriate for serverless.

Memory limits: function instances have maximum memory allocations, ranging from 128 MB to several GB depending on the platform and configuration. Memory limits are rarely a constraint for redirect management functions, looking up a redirect rule in KV and returning a redirect response requires minimal memory. Large redirect rule sets should be stored in external KV stores rather than loaded into function memory.

Concurrency: serverless platforms handle concurrent requests by running multiple function instances simultaneously. If 10,000 requests arrive simultaneously the platform runs 10,000 concurrent function instances, each handling one request. This automatic concurrency scaling is one of serverless’s most significant advantages, traditional server applications require explicit concurrency management and are limited by available server resources.

Serverless for redirect management

Serverless architecture provides specific advantages for redirect management infrastructure, enabling scalable, low-latency redirect serving without server management overhead.

Elastic scaling for redirect traffic: redirect traffic is often unpredictable, brand protection domains may receive sporadic traffic, campaign-specific redirect domains experience traffic spikes during active campaigns, and site migration redirects handle the full traffic volume of a site during transition periods. Serverless scales automatically to handle any traffic volume, a redirect function handling 100 requests per day scales seamlessly to handle 100,000 requests per hour during a traffic spike without pre-provisioning.

Zero infrastructure management: redirect management platforms built on serverless infrastructure require no server provisioning, operating system management, security patching, or capacity planning. The platform team focuses on redirect rule logic and management interfaces rather than infrastructure operations. This operational simplicity enables small teams to build and operate redirect platforms serving significant traffic volumes.

Cost efficiency for variable traffic: redirect domains often receive uneven traffic, some domains are highly active while others are dormant. Serverless billing based on actual execution means dormant redirect domains incur no compute costs during quiet periods. Traditional server-based infrastructure would charge for server time regardless of whether requests arrive, serverless aligns costs with actual usage.

Edge deployment compatibility: serverless functions deploy naturally to edge networks, the same execution model that works in a regional cloud data centre works at edge nodes globally. Cloudflare Workers are serverless functions deployed to Cloudflare’s edge, redirect rules execute at the edge node nearest to each user. The serverless model enables edge deployment without per-location infrastructure management.

Rapid rule deployment: serverless function deployments propagate quickly, seconds to minutes for global propagation. Updating redirect rules, either by deploying new function code or by updating KV-stored rule data, takes effect globally within seconds. This rapid propagation is operationally important for redirect management, configuration changes should take effect immediately rather than waiting for server deployments.

Serverless limitations

Serverless has limitations that affect how it is used, understanding these helps design appropriate redirect management architectures.

Cold start latency: container-based serverless platforms experience cold starts that add latency to first requests after idle periods. For redirect management this is a concern when redirect domains receive infrequent traffic, the first visitor after an idle period experiences cold start latency. Isolate-based platforms like Cloudflare Workers eliminate cold starts, making them preferable for redirect management where consistent low latency is important regardless of traffic patterns.

External data store dependency: stateless function execution requires external data stores for redirect rule persistence. KV lookup adds latency to each redirect request, typically 1-10ms for edge-colocated KV stores. This lookup overhead is acceptable for redirect management, total redirect response time of 15-30ms including KV lookup is far faster than origin-based redirect processing. But it requires careful data store selection, a slow or distant data store degrades redirect performance.

Limited execution context: the restricted execution environment of serverless functions, no filesystem access, limited system calls, constrained execution time, is appropriate for redirect management but limits use cases requiring traditional server capabilities. Redirect management functions fit naturally within serverless constraints.

Vendor lock-in: serverless functions use platform-specific APIs, Cloudflare Workers KV API, AWS Lambda event format, that create dependencies on specific cloud providers. Migrating a serverless redirect management implementation from one platform to another requires rewriting platform-specific integrations. Designing for portability, using standard Web APIs where possible, reduces but does not eliminate lock-in.

Serverless platforms for redirect management

Cloudflare Workers: the leading platform for edge-executed redirect management. Isolate-based execution eliminates cold starts. Global edge deployment to 200+ locations. KV storage for redirect rule databases. Tight integration with Cloudflare DNS, CDN, and SSL infrastructure. Many redirect management platforms are built on Workers.

AWS Lambda: the original and most widely adopted serverless platform. Container-based execution with cold starts but extensive ecosystem integration. Lambda@Edge deploys functions to CloudFront edge locations, closer to users than regional Lambda deployments. Well-suited for redirect management integrated with broader AWS application architecture.

Vercel Functions and Edge Functions: serverless functions integrated with Vercel’s deployment platform. Regular functions run in AWS Lambda infrastructure. Edge Functions run on Vercel’s edge network using Deno. Natural choice for redirect management on Vercel-hosted Next.js applications.

Netlify Functions and Edge Functions: similar to Vercel, serverless functions integrated with Netlify’s platform. Edge Functions use Deno runtime. Appropriate for Netlify-hosted sites requiring redirect management beyond Netlify’s built-in redirect configuration.