Although in this post we saw how to implement strangler fig for synchronous operations. Let’s see how we can handle scenarios when the monolith uses message brokers as mode of communication between services. We will be looking at below mentioned approaches.
Content based routing
Almost all the widely used message brokers have inbuilt routing mechanisms.e.g. Rabbitmq has exchanges. These routers can be configured to route messages based on certain binding keys or the content of the incoming messages. Therefore, the incoming messages to the monolith are simply routed to the new microservice via a new queue. This technique does not require any changes to the monolith. But downside is that we will be adding smarts to the pipes which is something we need to be very careful about. Remember, keep the pipes dumb and the endpoints smart. On the flip side, since we are migrating these smarts will be temporary.
Selective consumption
In this approach instead of adding a new queue, the message is read from the same queue. Existing service’s message selector can be manipulated to ignore the messages. And the new microservice’s message selector can be changed to read the messages from the same queue. As is explained, this requires change in the monolith as well. In case the changes need to be reverted they need to be reverted in both the places. This technique is helpful if the number of places where changes to message selector required are minimal. In case they are more then its better to go with an alternate option.
What if the new implementation has issues?
This is easier to be implemented with content based routing. In case of an exception, manipulate the message to match the selector for old monolith’s consumer and have the message put back onto the old queue.
Since selective consumption is much more invasive and highly coupled technique, implementing a fallback will be a much more tedious exercise in that situation.