Edge functions: where the edge breaks under load
Processing requests at the edge looks like free acceleration: code closer to the user, origin offloaded, response more even. It breaks on three things — handler initialization, access to shared state, and consistency with the data source.
Cloudflare Workers and related runtimes were built for short stateless operations; as soon as stateful logic appears in them, platform limits show up.
A traffic spike hits first: a node serves many handlers in a shared pool, and while some are warming up, others wait their turn. Then the limit on external subrequests kicks in — the handler errors out, and the client gets a 5xx response instead of a redirect or current price.
Errors during a spike arrive in batches, not scattered: a node that has exhausted its resource refuses all requests in a row, including those that could have been served from cache.
The second CDN bottleneck is concurrent writes to shared state.
An impression counter, a per-address limit, a cart: anything stored in handler memory, under parallel requests across different nodes, is read and overwritten at the same time, and some changes disappear without a single line in the logs.
This is closed by moving state to shared storage and using a per-user key, but every access to it adds latency — it has to be bought back with a local layer with a short time to live.
The third class of failures is desynchronization with the data source.
Cache rules and the moment of publication on the server are in no way connected: while the edge holds an old version, the buyer sees a product withdrawn from sale, and support receives requests that could have been avoided. Tag invalidation and key versioning close this, but require discipline in forming the object name.
At the same time, overload of an edge node is an honest signal: if the share of failures grows with unchanged load on the origin, the problem is not traffic but the design of the logic. We analyze how this is closed — from the state schema to degradation behavior.
What changes in service operation after moving logic to the edge
Logic moved to the edge runs in the network node closest to the user, not on the origin.
Token validation, redirects, header normalization, traffic splitting between variants, and filtering out junk requests move there — everything that previously occupied a connection to the primary environment.
Cloudflare Workers and related runtimes run such code on every node, so it scales with audience geography rather than origin capacity.
Response time stops depending on distance to the origin: the response is assembled in the same region where the user is located. Static and cached responses are returned immediately, dynamic ones are computed locally, and only what requires database access reaches the origin.
The spread between near and far regions is smoothed out, and typical requests are accelerated many times over.
The share of requests that do not reach the origin is the main metric of the effect.
Redirects, cache delivery, session validation, and parasitic traffic filtering are handled at the edge: a noticeably smaller portion of requests reaches the origin, and this share steadily holds at the level of tens of percent of the total flow.
At the same time, a whole class of failures goes away — the origin stops being the single point where all requests converge at once.
During peaks — a sale, a publication, an external spike — nodes absorb the load and continue responding while the origin recovers, and the origin itself receives an even flow instead of a wave.
The load on it decreases so much that seasonal spikes no longer require pre-provisioned capacity headroom.
Approaches to request handling: comparison of modes and limitations
CDN-side caching rules cover most tasks without any code at all: caching by path and extension, cache key normalization, redirects, different TTLs for static assets and markup.
As long as logic does not depend on request content, the edge network is more predictable than any runtime — there is nothing to build, nothing to update, and nothing to roll back.
As soon as logic appears — geo overrides, A/B distribution, link signing, assembling a response from several sources — edge compute is needed.
Lightweight functions at the edge are designed for short modification of a request or response, while full-fledged runtimes like Cloudflare Workers provide a regular runtime but with their own limits.
The common set of runtime restrictions is the same: no arbitrary libraries without bundling, no direct database access, separate deployment, logging, and rollback models.
| Option | When it fits | Limitations |
|---|---|---|
| Caching rules without code | Static assets, redirects, cache key, headers | Logic does not depend on request content; rule order is hard to maintain |
| Lightweight functions at the edge | Header modification, signature validation, redirect | Hard limit on execution time and code size, no network calls from the function |
| Runtime at the edge | Personalization, A/B distribution, response from several sources | CPU time and memory limits, its own bundling and module format |
| Server-side layer before the origin | Heavy logic, database access, long computations | Network latency, another scaling and failure point |
The server-side layer removes edge limits but adds network latency and a second point of failure — it is placed where the edge technically cannot handle it.
The working scheme is usually hybrid: the edge caches and filters out noise, the layer does the heavy work, and CDN caching rules and edge overrides do not conflict.
Implementation stages: from traffic analysis to handover to operations
We work sequentially: first we measure what actually arrives at the edge, then we design rules, and only then do we write code. This way edge logic does not break existing sessions and cache, and the result is visible in metrics, not in feelings.
- Traffic audit. We collect request statistics: share of static and dynamic, geography, response repeatability. Separately, we count which paths can be served at the edge and which must go to the origin.
- Routing scheme. We prepare a rule map: where cache works, which path the function handles, how headers and cookies are passed so as not to break authorization and personalization.
- Edge logic setup. We implement functions: redirects and canonical addresses, header normalization, rate limiting, content delivery from the nearest point. We account in advance for runtime and memory limits.
- Testing on a test environment. We run scenarios on a copy of the configuration, compare edge and origin responses, and check behavior when the origin is unavailable — a correct fallback path must work.
- Testing on production traffic. First we enable logging mode, then on a small share of requests. We compare response time, cache hit rate, and error count; rollback is by switching one rule.
- Handover to operations. We transfer the configuration to repositories, deployment through a pipeline, dashboards and alerts, rollback procedure, and instructions for your on-call shift.
Implementation artifacts: configurations, policies, procedures
After implementing edge functions, the team is left with not a checkbox report but a working kit: files in the repository, diagrams, and procedures. Using them, a change can be released and rolled back without our involvement — this is the check that the handover has taken place.
- Route configuration. Binding paths and hosts to handlers, their order of execution, exceptions for service and static requests. The file sits next to the code and goes through review with it.
- Request handling scheme. The path from the browser through the point of presence to the origin: where headers are inserted, where cache is read, where the request goes to the application server.
- Access and key policies. Roles, token scopes, environment separation, secret rotation procedure, and storing them in a secure vault instead of function code.
- Check sets. Tests of function behavior on the pre-production environment, comparison of headers and response codes, running cached routes under load.
- Rollback procedure. Step-by-step return to the previous rule set, trigger conditions, and the sign by which it is clear that the edge has returned to a working state.
- Release procedure. How a change reaches production: branches, review, deployment order, who confirms readiness.
- Infrastructure documentation. Description of environments, variables, responsibility areas, and typical operations — so a new engineer can figure it out without messaging the solution author.
Case study: how response time was reduced and a class of failures removed
What was on the origin
The origin served not only data but the entire wrapper of the request: redirects, security headers, language and currency selection, static assets, markup for interface tests.
Each such response traveled the full round trip to the origin, and during sale hours it hit the limit not on data but on the number of connections. The share of error responses reached 2.4%, and the 95th percentile response time tripled relative to quiet hours.
What was moved to the edge
To the Cloudflare edge, we moved the layer that does not need a database: address normalization and redirects, security headers, geo and language routing, static asset delivery, markup for interface tests.
The cache key was assembled from region, language, and authorization flag — personalized responses are still assembled at the origin, while the rest is served from the point of presence closest to the user. Part of the logic in edge functions absorbs short spikes entirely, without reaching the origin.
What happened after the move
The median response time decreased many times over, the 95th percentile — threefold. The share of error responses fell from 2.4% to 0.15%, meaning the class of failures that previously appeared precisely at peak was gone.
The load on the origin during sale hours decreased by more than half with the same traffic, and the peak day passed without degradation or manual intervention.
Changes at the edge are rolled out as a separate release and rolled back within minutes, so edits to logic no longer require rebuilding the main application.
Response metrics and error share by region are brought into a common dashboard — regression is visible before buyers notice it.
How edge functions differ from a server-side layer
A reverse proxy before the origin and edge logic solve different tasks, although from the outside they look similar.
The proxy receives a request, enriches headers, filters out junk, and passes it on — processing still happens on a specific server, and the network path to it remains full.
An edge function executes where the user hands over the connection: at a point of presence, next to the TLS termination point and cache.
Latency is reduced in different ways. A proxy removes one hop to the origin and part of the load from the application, but not the processing itself. Edge logic removes that too — as long as the computation is closed over data residing at the node.
As soon as a database write or origin read is needed, the request still goes back, and the gain dissolves in the same hop.
Data access is the main constraint. At the edge there are distributed key-value stores with eventual consistency: no locks, long transactions, or familiar SQL connections. Routing, token signature validation, interface variants, and header normalization are moved there. Operations with balances, orders, and permissions remain at the origin.
Debugging distributed logic is more expensive. A local environment reproduces the node only partially: cache behavior, geography, and limits differ, and the call stack is assembled from logs of several nodes and the origin. On a proxy, there remains one process with a familiar debugger and predictable log.
Total cost of ownership is calculated by engineering maintenance, not by per-request pricing. Edge code wins on large volumes of uniform traffic but adds failure points and requires a separate deployment discipline.
A proxy is easier to maintain, but it remains a single point on the request path. The boundary runs along data: logic without consistent state — edge, with it — origin.
Technical doubts before launch: environment, limits, rollback
Before launching edge functions, a technical lead checks not the code but the system's behavior under bad conditions: origin unavailability, peak load, partially migrated routes. We address these questions at the start and record the answers in the configuration, not in chat.
The runtime is rented from a cloud provider, but responsibility for settings, limits, and behavior under load remains with the team. Therefore, before rollout we determine the owner of the configuration, the location for storing secrets, and the telemetry sources.
What happens if the origin stops responding?
Each rule gets a timeout and fallback behavior: return the cached response, return a stub, or pass the request through directly. We set the timeout shorter than the client's waiting budget so the visitor does not wait for a failure.
Can only part of the routes be moved to the edge?
Yes — routing is configured by path prefixes: one section goes to the edge, the rest work as before. This way we compare metrics of the two environments on the same traffic and expand coverage gradually.
What does rolling back a change look like?
The configuration lives in a version control system, and deployment goes through validation while preserving the previous state. Rollback is a return to the previous revision and redeployment: minutes to restore instead of an hour of manual edits.
What happens under peak load?
We set concurrency limits in advance; when they are exhausted, requests are served by the main application environment — degradation instead of failure. Before launch, we run a load profile and look at the error share and response time.
Let's discuss the task: what is needed for an estimate and work plan
The section below is about how a task turns into a work estimate and implementation plan.
So that the calculation relies on the actual state of the perimeter rather than general considerations, we need access and inputs: then we see the real caching rules, the volume of configuration, and the current limitations.
What we will need from you as input:
- Read-only access to the CDN panel and DNS zone — we will look at records, caching rules, redirects, and certificate binding.
- A repository with perimeter configuration and the build pipeline: we will assess what is deployed automatically and what is edited manually.
- A list of domains and subdomains with roles — which serve static assets, which work with the API and personal accounts.
- Scenarios for edge functions: A/B distribution, geo redirects, token validation, header transformation, serving a stub when the backend fails.
- Load profile: peak requests, share of dynamic responses, user geography, and sensitivity to latency.
- Constraints: change windows on the production environment, rollback requirements, and security policy with logging.
- Responsible people: who owns DNS and who confirms rollout to production.
At the output, you receive a work estimate, a modification scheme with responsibility areas, and a staged implementation plan — with a test environment, rollback points, and checks at each step. Describe the task and send access — we will come back with an estimate and plan.