Event driven architecture
Event driven architecture is popular to design distributed systems and used to produce highly scalable and high performant systems. It provides loose coupling across services and supports asynchronous communications. Main basis of this architecture is understanding or identifying the main events in domain and designing impact for these events.
There are 4 main components to build this architecture:
Initiating event: An initial event which starts the entire workflow.
Event broker: Broker which maintains channel/queue/topic to publish events.
Event processor: Subscribers to the events which will take action on the event
Processing event: Letting the whole system know about the outcome of action taken taken by event processors after consuming events. This could be the initiating event for another workflow.
Different kinds of events
- Event Notification: This event is used when a system sends event messages to notify other systems of a change in its domain. A key element of event notification is that the source system doesn’t really care much about the response. Often it doesn’t expect any answer at all, or if there is a response that the source does care about, it’s indirect. There would be a marked separation between the logic flow that sends the event and any logic flow that responds to some reaction to that event.
- Event sourcing: The core idea of event sourcing is that whenever we make a change to the state of a system, we record that state change as an event, and we can confidently rebuild the system state by reprocessing the events at any time in the future. The event store becomes the principal source of truth, and the system state is purely derived from it. For programmers, the best example of this is a version-control system. The log of all the commits is the event store and the working copy of the source tree is the system state.
- Event-Carried State Transfer: his pattern shows up when you want to update clients of a system in such a way that they don’t need to contact the source system in order to do further work. A customer management system might fire off events whenever a customer changes their details (such as an address) with events that contain details of the data that changed
2 ways to implement event driven architecture
EDA can be implemented in 2 ways:
Mediator topology: In this there is an orchestrator/event mediator sitting who is orchestrating across services to take action based on events happening in system. This controls the workflows, commits and rollbacks in case of failures. Using this topology it becomes easy to control and change the workflow but it might also become single point of failure.
Broker topology: There are no mediator, producers are producing events and interested consumers subscribed to events to take actions. Rollbacks in case of errors are very tricky and complex in this topology. This is highly distributed and decoupled.
Caution of advise while using EDA
- Identify events which are of concern for business, something called domain events. Treating everything as events and needs to be asynchronous will bring unnecessary complexity in system. Sometimes a simple call from one service to another is enough. If a process uses event driven architecture, it usually requires much more infrastructure to support it, which will add costs (as it will need a queueing system)
- Roll back across systems and events needs be thought through when designing events at first place and that brings more complexity with databases being involved.
- How would you track all subscribers when you need to make non compatible schema changes, like changing data types .
- Testing could be over complicated to think of all scenarios which can occur in system across services.
Almost all highly and distributed systems in industry are built using event driven architecture.
