Events & Weddings

In what turned out to be most opportune timing, I conducted a demo earlier today moving us towards an Event Driven Architecture utilising Solace as the message broker.

Why was it opportune timing? Because last night I attended a wedding. Which if you’re not aware, is quite a large event.

If we take the sum of our lives as a system we can reduce it down into all of the various events that happened, how we responded, the changes in state because of responses to those events and the eventual evolution of responses into the future (learning).

Now most of the systems that we as developers spend our time, building, fixing, deploying and enhancing are not nearly as complex as the human machine. However when growing to a certain level of complexity as occasionally happens, sometimes you need to sit back, relax with a cup of tea and ponder if all of the technical decisions that have been made to-date have been correct.

There’s a very good chance that they have, however that also doesn’t mean we can’t improve. Which is why we’re getting our feet wet with Event Driven Architecture.

Currently we’re in the situation where we have dozens of services, applications and systems running around, and keeping track of all the data that flows between is getting hard. There is data that flows through 10+ different systems. That depending on configuration for that particular piece, there could be 4-5 systems that are source of truth so keeping everything in sync starts becoming a priority.

That’s where Event Driven Architecture (EDA) comes into play. Instead of having something like this

You end with something more like

Or for something more colourful

We’re only just started to dive into, by so far the technical challenges have been fairly easy to work with and it is now clear that major obstacle is not the development of such a system, but it is instead the design of such a system. We will be spending a good chunk of time over the next few months designing out how things will work, which is something that we’ve probably not really done very well to-date. We’ve mostly built integrations in an ad-hoc manner when needed.

Things to think about become

• Topic hierarchy
• What queues, and how many of them
• Environment differences
• Versioning
• Big data updates
• Prioritisation
• Error handling
• Idempotent Events
• Auditing

I’m currently also in the pre-build phase of an open-source .net wrapper for the Solace .Net SDK to make implementation of Solace in Modern .Net 5/6 applications as easy as it to use Hangfire or Swagger.