In one of my previous articles, the Hollywood Principle, I introduced the concept of an event-driven architecture. This is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is underpinned by asynchronous messaging and often implemented using the Publish and Subscribe (PubSub) pattern. The premise of this pattern is that an event triggers messages for distribution to multiple subscribers. However, in order to implement an effective event-driven architecture, it is important to understand what an event is in context.

Let’s consider the first type of Event. Application developers, and more specifically UI developers are all too familiar with the concept of an event. A user clicking a button or moving a mouse is considered an event. Each event has an associated event handler to perform the specific action anticipated by the user. We’ll call these UI events and exclude them from this discussion since they are generally handled within the UI container.

Secondly, during some form of business process, an artifact may be produced (a file for example) which needs to be handed over to another system. The system creating the artifact needs to let the other system know that that artifact is ready for further processing. This can be considered an event. Likewise, a UI event handler may need to trigger a process in another system. These can also be considered events. We’ll call these process events.

Finally, we have the scenario where a business domain or entity is updated or created, via some process or another. The update of this entity can be considered an event since this update may be relevant or of importance to other systems. A good example of these could include a customer update, a payment or an account update. We’ll call these business events.

Process events nearly always involve only two parties; the producer of the event and the consumer of the event message. The producer of the event needs to be aware of the consumer of the event message. To support asynchronous behavior these events should be transported via standard messaging. Using PubSub is overkill in this context and should not be advocated as it clutters the PubSub topic range.

Business events are the ideal contenders for using PubSub since these are business activities that others may care about.

Let’s walk through an example – an online payment.

Using the UI channel, the user clicks the submit payment button. This “click” (UI event) might be handled by a function that validates all the required fields are populated. All these activities are encapsulated with the UI. Assuming successful validation, the payment request might be submitted to a payments engine asynchronously (a process event) since the payment may only be cleared later.

Within the payments engine, the payment request is processed. This process might involve using several external systems, including funds check, AML and fraud checks. Each of these systems might raise an event that other systems might care about (analytics, alerts, etc.). These systems might publish these events via PubSub using a topic relevant to the event: “overdrawn”, suspect persons” and “suspicious behavior”. Finally, the payment is cleared – this will trigger the final event – and publish the transaction via PubSub for other systems to react to (account balance update, balance SMS, analytics, etc.).

Reacting to events can be a very powerful architectural pattern – it promotes real-time responses and reduces “overnight” processing. But, it is important to know which messaging pattern to implement.

Photo by rawpixel.com from Pexels