In the previous part we’ve learned about the concept of an event, how to start thinking in terms of events, and what are the benefits of using the Event-Driven approach. We have all agreed that events are the core building blocks that enable asynchronous, loosely coupled communication between system components. But how do we implement an event in the first place? Several ways exist to design Event-Driven systems, each suited for different use cases.
Observer pattern
Observer, also called Event-Subscriber or Event-Listener, is a behavioral design pattern that lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they’re observing. It is a simple solution, with one particular benefit — it doesn’t require any middleware to connect publishers & subscribers.
void notifyAll() {
for (var s: subscribers) {
s.handleEvent(state);
}
}
void doStuff() {
state = new State();
notifyAll();
}
var publisher = new Publisher();
publisher.subscribe(new FirstSubscriber());
publisher.doStuf();
Advantages
- Simplicity. Observer pattern can be implemented with existing Object-Oriented programming language;
- It doesn’t require any middleware;
Disadvantages
- Events are not durable;
- They only exist within the memory of one process;
- As a system grows it becomes ever so difficult to manage many publishers and subscribers;
Use Cases:
Works well for in-memory event handling (e.g. UI updates, internal service events). It’s a good choice for monolithic applications of moderate complexity.
Such a solution has quite a few limitations and often it will not take that much time until you start looking towards integrating the Event Broker.
Event Broker
Event Broker is an external technology that works by publish-subscribe model or Pub/Sub across distributed systems, which means that multiple micro-services can communicate asynchronously without being directly dependent on each other.
