Event-driven architecture
Event-driven design pattern
Another architectural pattern that has made it possible to decouple monoliths, including the UI and still preserving strong communication between decoupled components, is the event-driven design pattern.
This pattern is very compatible with decoupled frontend implementations because, as you probably know, JavaScript in the browser uses an event-driven programming model, which facilitates an event-based type of communication between the UI and decoupled services in the backend, like microservices, in an e2e fashion.
Events producers and consumers
Thinking about event replication and propagation end-to-end, in a distributed system, may require for us to get familiar with more complex technologies, like event hubs, grids, and message brokers. You have probably heard about Apache Kafka or other event streaming technologies,and you may have heard that they have a very steep learning curve -not to mention that they’re server-side technologies and require some knowledge of backend languages and/or infra configuration in order to deploy the Confluent Servers -even when you can use the Confluent REST Proxy to consume messages from any frontend client, via the exposed APIs, without knowing anything about Kafka, providing the clusters are in place. But there are also some managed serverless options, that can simplify the integration with an event streaming or pub/sub message bus at a (serverless) backend level, to connect independently deployed UIs.
Let’s try to find a way to explain it, in simple words. When we’re designing an event-driven architecture, we typically have one or many components that publish events, and one or many components that subscribe to those events. The relationship can be one to many, many to many, or even many to one.
Events are known as messages in a message-driven context (or when the publisher expects a response from the consumer), and they can have topics, which is basically a way to categorize and filter messages. Sometimes, between the publisher or producer of messages, and the subscriber or consumer, there is a broker, that processes and routes those messages.
The important thing: the publisher and subscriber don’t need to know of the existence of each other, to operate, and this is why this pattern is so well suited to support composable systems that integrate independent components.
Go to a pull request implementing event driven, real-time notification features for a cloud based, serverless micro architecture deployment.