Targeted Event-Carried State Transfer
Another flavour of microservices’ integration
In my last post, I discussed Event-Carried State Transfer as a way to integrate microservices and examined its benefits and drawbacks. In this post, I want to demonstrate a slight variation of this approach I have seen implemented.
Below is the traditional Event-Carried State Transfer diagram I used in my last post as a reminder.
The variation I have seen out in the wild is Event-Carried State Transfer but targeted to consumers. This is usually done by breaking down the public event into multiple smaller ones with only the fields relevant to the target consumer.
All consumers usually get all the broken-down events and discard the ones not targeted to them. For example, in the above diagram, microservice C will get Microservices B and D’s targetted events but will not process them. It will only process its own targeted event.
This has the advantage of limiting changes to the targeted event associated with the consumer requiring that change instead of using one over-bloated event that changes whenever any of the consumers change.
However, the adapter responsible for breaking down these events will need to be extended every time a new consumer is added, negating some of the decoupling advantages.
There are, nevertheless, techniques to ease this coupling by allowing the adapter to load up and use runtime-discoverable interceptors deployed and owned by the consumers. The producer can load up these interceptors by scanning a pre-determined location locally. and invoking them within the adapter shown in the above diagram.
These interceptors check whether they are interested in the event, extract the subset of data they need and either let the producers publish the generated events or take charge of the publishing themselves. They only need to take over publishing if targeted events need to be sent to a targeted topic.
If any interceptors fail, the whole process is repeated to ensure all targetted events are successfully published.
