A/B Testing at the Edge with Rust

One of the most powerful features of edge computing is the ability to inspect and route traffic before it ever reaches your origin server. FastEdge gives you full programmatic control over request routing at every edge location worldwide.

In this post, we explore A/B Testing at the Edge with Rust — a core pattern for directing traffic intelligently across the global edge network. Instead of configuring complex reverse proxy rules or maintaining separate routing services, you write Rust code that compiles to WebAssembly and runs at every FastEdge point of presence.

How It Works

Serve different versions of your application to different user segments — all at the edge with zero origin impact.

The key advantage is latency: routing decisions happen at the edge location closest to the user, not at a centralized load balancer or origin server. For a user in Tokyo, the routing decision happens at a Tokyo PoP — the response never crosses an ocean unless it needs to.

Implementation in Rust

The FastEdge Rust SDK provides everything you need. Here is a complete routing implementation:

use fastedge::{
    body::Body,
    http::{Request, Response, StatusCode, Error},
};

#[fastedge::http]
fn main(req: Request<Body>) -> Result<Response<Body>, Error> {
    let path = req.uri().path().to_string();

    match path.as_str() {
        "/" => handle_home(req),
        "/api/" => handle_api(req),
        "/static/" => serve_static(req),
        _ => Response::builder()
            .status(StatusCode::NOT_FOUND)
            .header("content-type", "text/plain")
            .body(Body::from("Route not found"))
    }
}

This pattern — matching on the request URI in a simple match block — compiles to efficient WebAssembly with no external dependencies. For more complex routing needs (path parameters, wildcards), consider the matchit crate which implements a radix-tree router.

Deploying to Production

Once you've written your handler, build it and deploy via the FastEdge API:

cargo build --release

Upload the resulting .wasm binary and attach it to your FastEdge HTTP application. The new routing logic is live across 100+ edge PoPs within seconds.

Tip: Combine routing with other edge patterns — validate JWT tokens on protected routes, add GeoIP-based redirects for international users, and cache responses all within the same worker.

Performance Characteristics

FastEdge workers cold-start in under a millisecond. A simple match-based router adds less than 1µs to request processing time. Even with complex route tables of 50+ routes, the match overhead remains negligible compared to network latency — typically under 5µs.