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 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 artefact may be produced (a file for example)
which needs to be handed over to another system. The system creating the
artefact needs to let the other system know that that artefact 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.

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.

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 from Pexels