The Hollywood Principle

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:

1. publish event data via persistent queues to ensure delivery, and/or
2. expose APIs for retrieving published event data for reconstitution queries in the event of an error by the subscriber.

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