Subject Mapping and Traffic Shaping

The example of is straightforward. All messages the server receives on subject foo are remapped and can be received by clients subscribed to bar.

Wildcard tokens may be referenced via $<position>. For example, the first wildcard token is $1, the second is $2, etc. Referencing these tokens can allow for reordering.

For example with this mapping bar.*.*: baz.$2.$1, messages that were originally published to bar.a.b are remapped in the server to baz.b.a. Messages arriving at the server on would be mapped to baz.two.one, and so forth.

Traffic can be split by percentage from one subject to multiple subjects. Here’s an example for canary deployments, starting with version 1 of your service.

All requests to myservice.requests will go to version 1 of your service.

When version 2 comes along, you’ll want to test it with a canary deployment. Version 2 would subscribe to myservice.requests.v2. Launch instances of your service.

Update the configuration file to redirect some portion of the requests made to myservice.requests to version 2 of your service.

For example the configuration below means 98% of the requests will be sent to version 1 and 2% to version 2.

        { destination: myservice.requests.v1, weight: 98% },
        { destination: myservice.requests.v2, weight: 2% }

Traffic shaping is also useful in testing. You might have a service that runs in QA that simulates failure scenarios which could receive 20% of the traffic to test the service requestor.

myservice.requests.*: [{ destination: myservice.requests.$1, weight: 80% }, { destination: myservice.requests.fail.$1, weight: 20% }

Alternatively, introduce loss into your system for chaos testing by mapping a percentage of traffic to the same subject. In this drastic example, 50% of the traffic published to foo.loss.a would be artificially dropped by the server.

foo.loss.>: [ { destination: foo.loss.>, weight: 50% } ]

the remaining 2% is “lost”