Author: Cameron HUNT

In January 2021, I wrote that Event Driven Architecture (EDA) should be "Always Asynchronous." At precisely the same time, I argued that "the concept that we are actually trying to explain when we use the term 'Asynchronous' — within the context of EDA — might be better termed: 'Monologueous Communication'" (where no response is ever required). Nonetheless, 'Asynchronous' remains the dominant term in use today, and it was never certain that 'Monologueous Communication' was a good replacement. As the months have passed, however, I see more and more clearly how using the term 'Asynchronous' represents a major obstacle to our shared comprehension of EDA.

Let me give you an almost unbelievable example that I witnessed from the CTO of the global computing giant AWS at its recent re: Invent Summit in December 2022. Of course, it goes without saying that the CTO of AWS is as well placed as anyone in the world to explain to an ignorant public was 'Asynchronous' actually means, for which reason I find this example so incredibly useful (please do not take it as a pointless exercise in AWS-bashing).

It is always interesting to note how even today's Cloud giants continue to draw a largely imaginary line between Synchronous and Asynchronous HTTP Requests, such as in the case of a typical REST API call. This line, we are asked to believe, very clearly separates Synchronous Requests – where the Request is made and the caller holds the line until receiving a Response from the relevant HTTP API Endpoint – from Asynchronous Requests – where the caller fires off their Request, (typically) gets a 202 Status Code in reply, and then waits for the actual API Response via some other channel; such as a Webhook, WebSocket, or using the 'HTTP Polling' Pattern described by Microsoft in its Asynchronous Request-Reply pattern Article.

We read in this same Article that: "Most APIs can respond quickly enough for responses to arrive back over the same connection… In some scenarios, however, the work done by [the] backend may be long-running, … [and] it isn't feasible to wait for the work to complete before responding to the Request. This situation is a potential problem for any synchronous request-reply pattern… Some architectures solve this problem using a message broker to separate the request and response stages… But this separation also brings additional complexity when the client requires success notification, as this step needs to become asynchronous."

Despite the hype around ‘Event-Driven Architecture’ (EDA) over the past few years, I am confident that you will be unable to find a solid definition for ‘Event,’ on the web today. After an hour of research, the best definition I managed to find is one of several definitions provided by Red Hat: “We will define a software event as the immutable record that something happened within an application… Normally, events are broadcast to notify of change or replicate state across multiple applications.” Here, Red Hat are talking specifically about ‘Software Events’: each of which signals a ‘change of state’ in a particular ‘entity’ (e.g. Customer address changed) within a given distributed application.

This definition perhaps seems very straightforward, but what is not mentioned, is that there are in fact three different types of ‘Events’ according to today’s pundits:

When Vikas Anand, Product Director of Google’s Apigee API Management offering, gave the presentation "The Case for a Unified API and Event Strategy" during the recent EDA Summit of 2022, I was again shocked by a gleaming error in what was presented: “Microservices, while they’re providing a great deal of advantages, they also bring in complexity which you need to manage. We can basically manage this better by providing a solution which is called event-driven architecture. This produces a solution for this problem, of microservices and a solution at scale, where it provides the ability to reduce dependencies and complexities in your application, whilst still allowing the creation of more and more microservices.”

Although I genuinely have no idea what any of that means, an error was nonetheless evident in the associated slide:

In watching the 2022 EDA Summit presentation "Powering Your Real-Time, Event-Driven Enterprise with PubSub + Platform" by Shawn McAllister, CTO of Solace (sponsor of the Summit), I learned of the origins of his company. This article recounts his presentation with my personal synopsis. As he recounted, let’s “start with capital markets…where Solace started."

Presentation Highlights and Additional Commentary

Shawn began by stating: "Capital markets became digital…over 20 years ago…They had, of course, on-prem applications…but the magic really happened in these 'colocation centers,' ... data centers that are not owned by the bank or the buy-side firm... They’re shared, so they’re kind of like the clouds that you have today… and those colocation centers were then located close to the execution venues, where a lot of the trading happened."

Anyone watching the current (streaming?) video series of the 2022 EDA Summit is likely to once again be shocked by the number of EDA thought leaders making interminable references to event streaming. Why shocked? Because events are NEVER "streamed," and anyone claiming to understand EDA probably ought to understand that fairly fundamental point.

The Oxford Dictionary defines "streaming" as "a method of transmitting or receiving data (especially video and audio material) … as a steady, continuous flow, allowing playback to start while the rest of the data is still being received." Events, you are probably aware, are never split across separate payloads. Indeed, on major platforms such as AWS where event payloads are limited to a maximum of 256 KB, even then I have never seen an individual event payload that came close to exceeding this limit.