Intercepts provide a way to attach ad-hoc routing rules for a service deployed on the TrueFoundry platform. We can use it to redirect traffic arriving at a service to another one on the basis of a header. It can be useful to test a new release for a service by intercepting the traffic on the main service and redirecting it to the the copied service. This is useful in development purposes for rapid debugging specially if a lot of microservices are involved. Let’s consider the scenario below:
Let’s imagine we are working on the model microservice and currently the v1 version is deployed. While we can test the model microservice separately by issuing API calls, sometimes its more convenient to check the end to end flow with a new version of the model. To test this, we can swap the model-v1 with model-v2, but this will affect the experience of everyone in case model-v2 doesn’t work well. Or we need to duplicate frontend, backend and db to be able to test the entire stack separately. This can become very cost intensive and also a lot of manual work - specially if a lot of developers are testing things independently. Intercepts provide an easy solution to the problem by redirect a small percentage of the traffic to the model-v2 or redirect based on headers in the incoming request.
In this case, we can just make a request from the existing frontend with some header like MODEL_VERSION: v2 and configure the interceptor to redirect all requests going to model-v1 with that header to redirect to model-v2. This way the other requests to frontend continue to get routed to model-v1 and only the request that we are testing end up going to model-v2. This can be useful to test end to end scenarios without redeploying the entire stack for every single developer.

​
Using UI

  1. Before intercepts can be enabled for a service, we need to allow intercepts for that service.
  1. We now can start adding intercept rules
  1. To test the intercept you can send a request to the service with the header set to the value in intercept rule and verify that the request indeed lands on the service set as destination. Eg - curl -H "<header name>: <header value>" https://<service endpoint> . If the intercept rules don’t match, the request will continue to go to the original service.

​
Note:

A service if associated with an intercept cannot be deleted until the intercept is deleted first