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.
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.