Community
Inversion of Control: Don't call us, we'll call you.
Remember when you were a child, going on a long trip with your parents. Remember the frustration; “Are we there yet?”, “Are we there yet?” Now, as an adult - imagine or remember your own frustration from being nagged!
For both parties, this pattern is not ideal; children are frustrated with not knowing, while parents are frustrated with constantly being nagged. So, why do we think this pattern is OK in software architecture? Why do we ask systems to constantly check other systems for updates? Why do we allow this tight coupling?
Fortunately, computers are not human; they have no emotion nor a concept of time. They don’t mind constantly asking other systems for an update and other systems don’t mind being asked. All they do is check again and again so they can do something. This constant chatter between systems can, and does, have an impact. So, instead of asking systems to constantly "check for an update", why not configure them to react to an event – tell them; “I’ve done something you may want to know about”.
When something happens in Hollywood – the world knows about it; whether we choose to do something about it is our own decision. A reporter writing the story about an event does not know who will read the story or what they will do with the information they receive. The reporter only expects the newspaper will publish the story for all its subscribers to read.
In software architecture, we can publish business events using the publish-subscribe pattern (PubSub). Interested systems can subscribe to events based on an event topic and decide for themselves, what to do with the data received. In essence, when the source system has done its bit, it can publish data about the event via PubSub to the subscribers. Decoupling is important; the source system does not, and should not, care about what the subscribers do with the data – they have already completed their task.
Since the subscriber consumes the event data for their own purposes, it is their responsibility to complete their task within their bounded context. So what happens if the subscriber fails to react to the event (via an error or broken communication)? Is it viable to ask the publisher to replay the event? No! The subscriber cannot assume they are the only audience of the event. Just like the publisher is not aware of the subscribers, subscribers should also not be aware of one another. Imagine republishing an event that leads to duplicate communications to customers or duplicate actions!
We can:
While PubSub does seem like a simple pattern, implementation can be challenging. Publishing a single event using Change Data Capture (CDC), of multiple tables, is just one of those challenges. That's a whole new ball-game and a subject for another day.
Craig Hughes
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Boris Bialek Vice President and Field CTO, Industry Solutions at MongoDB
11 December
Kathiravan Rajendran Associate Director of Marketing Operations at Macro Global
10 December
Barley Laing UK Managing Director at Melissa
Scott Dawson CEO at DECTA
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.