Fastly Compute@Edge: why remote users wait for a response
Application logic usually lives in one region: the database is there, sessions are there, business rules are there. A user from another geography pays for distance on every request — the request travels to the origin and back, and only then does the first response arrive.
The longer the route, the higher the response latency, and not linearly: the farther from the origin, the more intermediate networks and the greater the variance between individual users.
The origin in such a scheme is a single point of failure for everyone at once. Channel degradation, connection pool overload, or scheduled maintenance in the region hit users in any geography equally, although locally everything is fine.
Perimeter caching does not solve the problem: personalized responses, permission checks, and data access still reach the center, which means every such request again travels halfway around the world.
If you slice telemetry by user geography, the picture becomes clear.
The median response in a nearby region and in a remote one differ by multiple times, and in the tail of the distribution the gap is even larger — that is exactly what feels like “the site is slow” with formally normal averages.
Separately, it is visible that the share of slow responses grows synchronously with the daily peak, when the load on the origin is maximum: not just one segment becomes slower, but everyone.
This is eliminated not by code optimization, but by moving logic to the perimeter.
Part of the processing — routing, token validation, assembling the response from cache, rewriting headers — is performed on the node closest to the user, and such a request no longer reaches the origin.
We break down how this is arranged on Fastly Compute@Edge and what exactly makes sense to move to the perimeter and what to leave in the origin.
What moving logic to the network perimeter gives
Logic that previously lived only in the origin is moved to the perimeter — to points of presence closest to the user.
In Fastly Compute@Edge it is compiled into a compact module and executed in isolation next to the cache, so processing begins tens of milliseconds earlier than the request would have managed to reach the source region.
Three measurable values add up to the effect. Response time on routes where there used to be an extra round trip to the origin drops from hundreds of milliseconds to tens.
The share of requests served at the perimeter, after moving reads and caching rules, reaches 90% and above, and the origin sees only cache misses and writes.
Origin offload is a direct consequence: instead of a stream of similar requests, only a small part reaches it, and at peaks it ceases to be a bottleneck.
Horizontal scaling stops running into server rebuilds and warm-up — capacity is added on the perimeter side, where replicas are numerous from the start.
A separate class of failures goes away — “a region goes down, the service goes down”: traffic is distributed between points of presence, and the loss of one site does not turn into service unavailability.
Perimeter caching works both as an accelerator and as an element of fault tolerance — part of the responses is served even when the origin is unavailable.
Options for placing logic: when what fits
Logic can be placed at three levels: at the provider's perimeter, in the content delivery layer, or in the application itself.
The level determines what is available to the code — short-lived request handlers with access to key-value stores or a full runtime with a database and background tasks.
| Option | When it fits | Limitations |
|---|---|---|
| Edge computing at the perimeter (Fastly Compute@Edge) | Token validation, redirects, header normalization, assembling a response from cache and key-value | Sandbox: no long-lived connections or local disk, a trimmed set of system calls, a time limit for request processing |
| Rules in the delivery layer | Routing, cache policies, distribution by region | Only declarative rules — complex logic cannot be expressed |
| Multi-region with containers | Long-lived connections, database work, background tasks near the user | Data replication and routing between regions, more complex state consistency, more failure points |
| Core in one region | A single database, regulatory requirements, rare peaks | Latency for remote regions: the perimeter covers only static content and part of dynamic content |
Choosing a deployment scheme is not either-or: the perimeter usually covers 70–90% of requests, while the core remains for what requires state.
We move routes one at a time and at each step compare the response with the previous scheme — rollback is held in a single configuration change.
How we build the edge layer: stages of engineering work
We start work with measurement, not with setup: until the real traffic profile is visible, moving logic to the periphery remains a guess. We capture the picture by requests and only after that assemble the scheme.
- Load audit. We analyze logs for a representative period: the ratio of static and dynamic content, geography, response repeatability, and where time is lost. The output is a list of routes that benefit from the periphery and those that are cheaper to leave as is.
- Routing scheme. We fix which paths are served by the edge layer, which go to the origin, by which keys the response is cached, and what happens on a miss. We agree on the scheme before work: redoing routes on a live site is more expensive than on paper.
- Edge service setup. We build modules on Fastly Compute@Edge: logic is compiled to WASM and executed next to the user. Test and production environments are separated, configuration is described as code — the environment is reproduced, not configured manually.
- Testing on production traffic. We enable it on a small share of requests and compare with the current path by response time, error rate, and cache hits. The rollback threshold is set in advance: exceeding it automatically returns to the previous route.
- Handover to operations. We provide route documentation, caching policy, monitoring dashboards, alerts, and the rollback procedure. After that, your team changes routing rules — without our involvement.
After handover, we stay in touch for incidents, but the layer already lives its own life: it is covered by checks and understandable to those on duty.
Deliverables: configurations, diagrams, and procedures
The documentation set is not an appendix to handover but part of the result: with it, your team can edit the Edge service itself, publish a new version, and roll back an unsuccessful release without waiting for us.
- Deployment configurations — declarative files describing services, domain bindings, routes, and environment variables; versioned together with code and transferred between environments without manual edits in the panel.
- Request flow diagram — from the point of presence to the response: where the cache triggers, where edge logic executes, which headers and cookies change along the way.
- Access policies — roles and scopes in the panel, key issuance rules, secret storage scheme, and rotation procedure.
- Rollback procedure — step-by-step return to the previous version, launch criteria, and the maximum time within which the procedure must complete.
- Team instructions — how to build and publish a change, how to read logs and metrics, what to do in case of degradation, and whom to hand the issue to.
- Pre-publication check procedure — build without warnings, compatibility tests, cache warm-up, and control requests after traffic switching.
- Monitoring and alerting scheme — which indicators are collected at the edge, at which thresholds a signal arrives, and who handles it.
The set lives together with the service: when the architecture changes, we update the diagrams and procedures rather than leaving them in their original edition.
Handover includes a walkthrough — your engineers go through each item in their own environment rather than reading theory.
Case: faster response for a distributed audience
What it was like before moving logic to the periphery
Audience distributed across three regions, while response assembly happened in one place. Connection negotiation and the return path produced a median response of 0.8 s, and for users in a remote region peaks reached 2.5 s.
The origin received all traffic — static, personalization, data requests — so capacity was kept with headroom for peak, and when a region failed, before switching to backup the service returned errors for several minutes.
What was changed and what happened
Personalization, assembling the response from fragments, cache key computation, and routing between regions were moved to the periphery; WASM modules run on nodes next to the user.
The origin was left for data writes and authorized requests — the share of calls to it dropped from 100% to 18%, and the median response for remote regions dropped to 0.12 s.
Separately, we checked behavior during a region failure: a neighboring node accepts traffic in seconds, the error rate does not exceed the usual background, and rollback is done by enabling the previous build.
We ran the build and comparison of before/after metrics on Fastly Compute@Edge — that is why a similar edge computing case can be reproduced on another project by transferring configurations rather than rewriting logic.
What to do if part of the services is already deployed in one region?
Partial migration is a working scheme, not a compromise: the core remains in the existing circuit, while what benefits from proximity to the user moves to the perimeter — routing, static content delivery, token validation, request normalization. This allows migration to begin without stopping the product and without rewriting working services.
The hybrid scheme is built on analyzing the incoming request: by host, path, or header, traffic is divided between the existing circuit and Fastly Compute@Edge.
The share is moved with a managed switch — from one test route to the full volume, and at any moment it is returned back with a single configuration change.
Gradual migration proceeds one route at a time: the handler is deployed next to the current logic, responses are compared on identical requests, and discrepancies are resolved before switching users.
Then the route is moved to the perimeter, while the old path remains a cold backup during observation.
We fix the boundaries in advance: state, transactions, and background tasks remain in the existing circuit; the perimeter handles stateless logic. Otherwise, migration will run into data desynchronization, and rollback will cease to be safe.
Result: part of the load leaves the core, response times for external users level out, and migration can continue in parts — without a single switchover date and without risk to already working services.
Technical doubts before moving logic to the perimeter
Moving logic to the perimeter — on Fastly Compute@Edge or a similar platform — changes not only latency but also the class of failures: the network edge becomes the point through which all user traffic passes. Below are the objections that most often come up at the evaluation stage.
What happens if an edge node fails?
Requests go to healthy nodes in the same zone, and if the entire zone is unavailable — to a neighboring one: latency increases, but not service failure. Nodes are removed from rotation based on health before they start returning errors. We do not keep state and sessions on the periphery — we move them to storage.
How to update logic without downtime?
The new version is built next to the running one, traffic is switched in shares: first a control share, then the main bulk. Responses of the two versions are compared on the same stream, rollback takes seconds — the previous build remains available.
Can changes be tested before production rollout?
The same build is run locally, then replayed on recorded production traffic with comparison of old and new version responses — discrepancies are visible before switching, not after. Separately, we check timeouts and partial failures of internal services.
How to limit access to internal services?
Logic accesses internal services only via allowed routes, with request signing and short-lived tokens; secrets are injected during execution and do not enter the build.
Direct addresses are closed, and only what benefits from proximity to the user goes through the perimeter: access checks, routing, response assembly.
Let's discuss the task: where to start moving logic
Moving logic starts not with code but with an inventory of what already runs on the origin.
To discuss the task substantively and come back with an implementation estimate and work plan, we need a set of inputs from you — part is covered by access to the repository and configuration, part by a short call with the engineer who maintains the current stack.
- List of routes and rules that currently live on the origin: redirects, security headers, traffic distribution, geolocation and language conditions.
- What is critical for latency and what can be left as is — this forms the pilot area.
- Authorization scheme: where tokens are issued, how signatures are verified, where keys are stored.
- External dependencies of the logic: internal APIs, caches, queues, analytics systems.
- Execution environment constraints: allowed response time, memory volume, build size at publication.
- Environment requirements: how many stands are needed, how changes are released, how rollback is done.
- Target indicators: response time at the periphery, share of requests without origin access, behavior on origin failure.
After the conversation, we assemble a plan: a pilot area with a limited set of routes, acceptance criteria, the procedure for moving the rest, and rollback points.
The implementation estimate is calculated based on the volume of rules and the number of dependencies — the more complete the inventory, the more accurate the timelines.