Migrating between two versions (backends) of an API

I’ve been researching various reverse proxy/API gateway/service mesh tools to find something that would aid the migration between two versions of an API.

Customers will be migrated one-by-one so the first requirement is that I’m able to route to the correct backend based on the customer’s API key. Ideally this would be an external service call (since keys can be refreshed/rotated) that can be cached for some period of time in Linkerd.

The second requirement is that should a customer be migrated, if they receive a 404 from the new API I would like to reissue the same request to the other backend (since we will not be migrating data). I had a look at the various retry/circuit breaker options in Linkerd but couldn’t see any way to do dynamic routing on a per request basis, based on a HTTP response code.

Can anyone confirm if Linkerd supports these two features?


With Linkerd 2.4.0 we have support for simple weight based traffic splits, following the SMI spec: https://linkerd.io/2/features/traffic-split/

The features that you’ve described, the logic around retrieving keys and routing based on those keys, are usually implemented at the API gateway level. In the Linkerd proxy, we maintain performance by limiting conditional logic to load balancing and lightweight configuration options. We generally avoid anything that includes evaluating the request body itself, or the user making the request.

So, for the first feature, we don’t support this level of traffic management. I’m thinking through ways that we might be able to implement the functionality using our traffic split feature. However, since that’s a weighted distribution mechanism, I’m not sure that I’ll be able to implement something with the level of request introspection that you’re looking for.

Regarding circuit breaking, we are currently discussing internally what circuit breaking functionality means in Linkerd. I hope that we’ll be able to retry traffic to a different host/service based on response codes from another service, but I can’t say for certain.

Thanks for your question and for being part of the Linkerd community. If you have follow-on questions, you can write back here or join us in our slack channel https://slack.linkerd.io


Hi Charles,

Thanks for your prompt reply. With regard to the circuit breaking, it seems this is a common approach across service meshes/reverse proxies in that it’s really designed for handling failures on a backend rather than dynamically re-routing requests.


@benfoster I totally agree with you! You can expect the same level of quality from our circuit breaking that you’ve seen in other features of Linkerd.