Cloudflare Workers setup: where content delivery breaks
While load is steady, the bottleneck is invisible: the server has time to serve markup, static assets, and interface responses.
At peak load, parallel requests become many times greater, the processing queue grows, and server response latency exceeds the limits assumed during design.
This is noticeable not from graphs, but from user behavior: the interface lags exactly during the hours when the main traffic arrives, some requests time out and go to retry—and the retry again lands on the same overloaded node.
The second half of the problem is geography. Requests from remote regions travel the entire route to a single node, and only there does processing begin. Each hop along the route adds time to the response, and a link failure on one segment leaves an entire region without service.
Serving static assets amplifies the effect: images, scripts, and fonts are requested separately from markup and each time traverse the same path to the center. Between releases their content does not change—they are not needed by a node busy with logic and database work.
Thus a point of failure forms: one server is responsible for compute, content delivery, and requests from all regions at once. We break down how Cloudflare Workers removes this load from the center and moves part of processing closer to the user—to where they open the page.
What changes after moving logic to the network edge
When request processing moves to the network node closest to the user, the origin server stops being the entry point for all traffic.
Redirects, header parsing, test variant forks, page fragment stitching, and static delivery are resolved at the edge—Cloudflare Workers executes this code in the same node where the user's connection terminates. Only requests that actually need the database reach the server.
Offload is measured by the share of removed traffic: on a typical catalog or promo page, 60–80% of requests never reach the server—they are closed by edge caching rules.
The cache key is set by rules: what to count by page URL, what to account for by cookies, what not to cache at all. Response time comes from there too—a compute node in the user's region responds many times faster than a server on another continent.
Resilience to peaks changes structurally. Previously, a spike from a newsletter or publication hit the number of workers and the request queue; now the heavy part of compute scales at the edge, and the server receives a smooth flow.
We separately move rules to "hot" routes—so a spike does not become a cascade of slow responses and errors.
A separate effect is the cost of downtime. If the origin server is unavailable, the edge continues serving cached pages and static assets: the storefront remains readable, the visitor does not see a blank screen and does not leave for a competitor.
This does not replace redundancy, but it moves a failure from the "site is down" class to "some scenarios are unavailable", and recovery fits in minutes instead of hours.
Operating modes and connection points: comparing approaches
At the edge, the problem is solved in three ways, and the choice is determined not by fashion but by where declarative description ends and code begins. Caching and routing rules are described by configuration—they are edited by whoever runs the infrastructure.
Custom logic is executable code: it works closer to the user, but takes on responsibility for behavior.
The difference is visible at the moment of failure. Declarative modes are predictable and reproducible from a config file, but they do not make decisions based on request content.
Code can do more—and therefore requires tests, versioning, and a rollback plan: an error replicates to all points of presence at once.
| Option | When suitable | Limitations |
|---|---|---|
| Edge caching | Static assets, images, API responses identical for everyone | Not suitable for personalized responses: the decision is made by URL and headers, the request body is not analyzed |
| Routing rules | Traffic migration, environment separation, redirects, canary shares | Linear logic: no data-based branching or calls to external services |
| Custom logic at the edge | Token validation, variant switching, assembling a response from multiple sources | Limited execution environment and time/memory limits; harder to debug |
In practice, modes are combined: routing sends to the function only those paths that truly need logic, and the rest is served by cache.
In Cloudflare Workers, all three levels are described in one config file, so the limitations of each approach remain local and do not become common for all traffic.
Setup and launch: stages of engineering work
The order of work when setting up Cloudflare Workers is more important than speed: changes on the perimeter are seen by all users immediately, so we go from facts to configuration.
First we analyze real traffic—which routes generate load, what share of requests is cacheable, where clients come from. The solution design is built on this data, not on the habit of "doing it as usual".
- Traffic analysis. We collect logs, group requests by routes and types, and mark where delivery degrades first—origin, entry point, or one overloaded route.
- Solution design. We fix what goes to the edge, what remains on the origin, how requests are routed, and what rollback scenario is used. The design is agreed before the first config change.
- Test bench. We spin up a preview environment with a copy of production rules and run scenarios: cold cache, content update, peak load. The bench does not touch the production domain.
- Configuration setup. We describe routing, caching rules, headers, and error handling; values are moved to environment variables so the bench and production do not diverge.
- Failure testing. We shut down the origin, serve stale cache, break a separate route—see what the user sees and how the environment recovers on its own.
- Production release. We shift a share of traffic, monitor metrics and logs, and if deviations occur, return the previous version with one action.
- Handover. We hand over configurations, the design, and the rollback procedure, and show the team how to view perimeter state after changes.
This order gives a predictable release: each stage ends with a verifiable result, not a promise.
What remains in the repository and documentation after handover
Handover is not the moment when traffic starts going through the network edge, but the state of the repository in which the next edit is safe for an engineer opening it six months later.
Therefore we agree on the artifact list before start and close it by checklist: without any item, the work is not considered complete.
- full project configuration, with test and production environments separated: deployment is reproduced with one command, without manual edits in the dashboard;
- routing rules—which paths and hosts go to Cloudflare Workers, what remains on the origin server, how match priority is set;
- handler sources with entry point descriptions: request, scheduled task, queue;
- solution design: request path from DNS to response, caching boundaries, data lifetime in layers, failure points;
- storage and binding configurations: key-value spaces, object storage, configured limits;
- update and rollback regulations: how a version is released, how traffic is switched, how quickly we return to the previous one;
- secrets handling rules: what is in environment variables, who has access, how rotation works;
- documentation: local launch, environment diagram, monitoring procedure, and responsible contacts.
As a separate block we hand over the observability procedure: metrics, alert thresholds for errors and latency, links to monitoring dashboards. Such a kit allows changing routes and logic without us—an edit does not turn into investigating someone else's project.
Case: reduced response time and offloaded the server
Before
The project is a service with a personal account and an external API: all logic lived on one cluster in one region. Every request, including static assets and reference data, reached the server, and during peak hours requests queued.
Response time at the 95th percentile held at 0.8 seconds, for users from remote regions—above one second; three quarters of server capacity went to repeated responses.
After
We moved compute for stateless requests to the edge, to Cloudflare Workers: routing, redirects, interface version selection, assembling a response from cache and reference data.
The cache key was built with headers and session attributes so personalized responses did not mix between users. Requests needing the database were left proxying to the server with retry and timeout limits—edge unavailability does not become a client error.
Response time at the 95th percentile—0.18 seconds, 72% of requests are processed at the edge, and the number of calls to the server was reduced fourfold. The cluster stopped being a bottleneck: when traffic doubled, no queue appeared on the server. Separately, a class of failures related to overload on repeated requests disappeared.
What to do if content is already delivered through a reverse proxy
Most often the compute edge does not land on empty space: traffic already goes through a reverse proxy, where encryption terminates, and cache, compression, redirects, and access rules live.
This scheme does not need to be torn down—the edge layer integrates on top of it, not instead of it.
The first step is inventory: export routing rules from the proxy config and compare them with what is actually visible in logs.
A significant part of the rules turns out to be legacy that no one dares delete, and it is exactly there that behavior divergence after migration is easiest to catch.
Next, mirror mode is enabled: the request goes both to the new edge and the existing scheme, and responses are compared by code, headers, and body. Divergences become visible before users see them, not after.
Phased migration goes from simple to complex: first static assets, redirects, and image delivery go to the edge, then routes with authorization, and only then everything else. Rollback at any stage is an edit to one routing rule, not redeploying infrastructure.
The proxy keeps the tasks that belong there: internal services, permission checks, integrations with a closed perimeter.
Routing converges to a single point of truth—duplicates are removed from configuration, behavior is tested on live traffic, and Cloudflare Workers stops being a separate island next to the main delivery.
Technical doubts: limits, failures, and rollback procedure
Platform limits are hit not by traffic, but by request processing duration, the volume of bundled code, and the number of simultaneous calls to external services.
A heavy synchronous call inside the handler hits the time ceiling first: the client gets an error instead of a response. Therefore we move heavy work outside the request—into cache, queue, and background jobs, leaving only routing and delivery in the handler.
What happens when a worker fails?
Each request executes in a separate isolated environment, so failure of one invocation does not bring down neighbors or stop the service entirely. The platform resumes execution on the next request, but already without the state that was in memory.
That means everything critical—counters, carts, progress—must live in external storage, not in module variables.
How to return to the previous version?
Deployment history is stored on the platform side: rollback is done by switching to a previous build, not by rebuilding from the repository. We keep routing by traffic shares, so rollback is first tested on a small portion of requests and only then fully enabled.
The rollback window is limited: old versions are evicted over time, so we pin significant releases separately.
How to know something went wrong?
We look at three values: the share of error responses, response time, and the number of exceptions in the handler. Events go to a common stream where the request ID reconstructs the entire chain—from route to storage access.
We set an alert on error growth above the normal background, otherwise noise from single failures masks real degradation.
Let's discuss the task and come back with estimate and plan
An estimate becomes concrete when there is something to estimate: how the current request flow is structured, what logic should run at the edge, which services and storages it accesses.
Therefore the first step is a short task review together with your team, without changes in the production perimeter. We need a task description, a test perimeter, and access; the rest is our work.
In response we return:
- Scope of work — broken down by areas: routing and traffic distribution, response caching, edge access checks, failure handling, and logging.
- Implementation plan — in stages with a verifiable result at each: pilot on one route, traffic share migration, full rollout. Between stages there remains a return point to the previous scheme.
- Timelines — for each stage, with a separate note of what depends on your side: DNS records, certificates, change window, test data.
- Configurations and policies — caching rules, request rate limits, environment separation, deployment rollback scheme to the previous version.
- Acceptance criteria — which metrics we consider the result: response time, share of requests processed at the edge, no error growth after switchover.
- Risks and limitations — what in the current architecture will hinder migration and how we work around it.
Describe the task—what should change in the system's behavior and by when it is needed. We will come back with a work estimate, implementation plan, and a clear scope.