Skip to main content

Request Routing

Overview​

Request routing refers to the ability to redirect requests coming into a given service to an alternative destination, such as a sandbox fork of the service, based on metadata contained within that particular request. This allows each sandbox to selectively replace only some services in the overall set of microservices with forks, so you can test unmerged changes without having to launch a copy of every service in the chain.

The necessary sandbox metadata for routing is automatically added to all requests that reach your services through a endpoint. If you additionally set up context propagation within each service, request routing can take effect not only for that initial request, but also for any subsequent service-to-service requests in the chain.

Routing Requests​

The requests can then be examined for sandbox metadata and either sent to a fork of the service or passed through to the baseline service.

Signadot supports two different routing approaches, distinguished by where the routing decision is made:

Destination-side Routing (DevMesh)​

With DevMesh routing, the routing decision happens at the destination service's pod. A DevMesh sidecar container on the destination service (e.g., Service B) examines incoming requests and routes them to either the sandbox fork or the baseline service based on metadata in the request.

The DevMesh sidecar is injected into baseline workloads and acts as a L7 HTTP or gRPC proxy that provides lightweight request routing functionality. The sidecar examines requests for sandbox metadata and decides whether to route them to a fork or pass them through to the main container.

Service A Pod              Service B Pod (with DevMesh Sidecar)
    │                             │
Main Container ──────────────────>│
    │                             │ DevMesh Sidecar
    │                             │ (Routing decision here) ⚡
    │                             ↓
    │                    ┌────────┴─────────┐
    │                    │                  │
    │              Sandbox Fork          Baseline
    │              of Service B         Service B
    │             (header match)    (no header match)

Source-side Routing (Service Mesh)​

With service mesh routing (e.g., Istio), the routing decision happens at the source service's pod. A service mesh sidecar on the source service (e.g., Service A) determines where to send the request based on the sandbox metadata and routes it directly to the destination's sandbox fork or baseline.

Service A Pod (with Istio Sidecar)     Destination Pods
    │                                   ┌─────────────┐
Main Container                          │  Sandbox    │
    │                                   │  Fork B"    │
    ↓                                   │  (match)    │
Istio Sidecar ─────────────────────────▶│             │
(Routing decision here) ⚡               └─────────────┘
    │
    └─────────────────────────────┐    ┌─────────────┐
                                  │    │  Baseline   │
                                  └───▶│  Service B  │
                                       │  (default)  │
                                       └─────────────┘

When to Use Each Approach​

The choice between DevMesh and service mesh routing is primarily determined by whether you already have a service mesh installed in your cluster:

  • DevMesh should be used when you don't have a service mesh or are using Linkerd.

  • Service Mesh routing (Istio) should be used when you already have Istio installed.

  • Gateway API (alpha) can be used when you have Gateway API resources (HTTPRoute, GRPCRoute). See limitations.

These mechanisms are described in more detail in the following sections.

Routing Mechanisms​

Signadot supports setting up request routing in the following ways: