Document updated on Oct 29, 2018
There are times when you have been working in a new version of your microservice, a complete refactor, a dangerous change, or any other valuable change that needs being careful, and it’s too risky to put it live as there might be issues that impact your end users.
The traffic shadowing or traffic mirroring functionality allows you to test new backends in production by sending them copies of the traffic but ignore their responses.
When you add a backend to any of your endpoints as a shadow backend, KrakenD continues to send the requests to all the backends as usual, but the responses from the ones marked as shadow are ignored and never returned or merged in the response.
Mirroring the traffic to your microservices allows you to test your new backend from the interesting perspective of seeing behavior in production. For instance, you could:
To define a backend as a shadow backend you only need to add the flag as follows:
{
"extra_config": {
"proxy": {
"shadow": true
}
}
}
With this change, the backend containing the flag enters into production, but KrakenD ignores its responses.
The following example shows a backend that is changing from v1
to v2
, but we are still unsure of the effects of doing this change in production, so we want to send a copy of the requests to v2
in the first place, but keep the end users receiving the responses from v1
only:
{
"endpoint": "/user/{id}",
"timeout": "150ms",
"backend": [
{
"host": [ "http://my.api.com" ],
"url_pattern": "/v1/user/{id}"
},
{
"host": [ "http://my.api.com" ],
"url_pattern": "/v2/user/{id}",
"extra_config": {
"proxy": {
"shadow": true
}
}
}
]
}
The documentation is only a piece of the help you can get! Whether you are looking for Open Source or Enterprise support, see more support channels that can help you.