Event Driven Architecture (EDA)
EDA is an architectural pattern which is based on system communication using events. The architecture facilitates communication by generating events and responding to events, thus providing a loosely coupled architecture.
For example, in a health care application, which is used by hospitals and diagnostic centers, let us take a look at the communication mechanism in the absence of EDA.
When a patient registers to be admitted to a hospital, there will be a series of actions like 'Create Patient Record', 'Allocate a ward room', ' Assign doctors and nurses' etc. Typically, there could be synchronous calls as shown below.
As we see in the above diagram, this system is tightly coupled and if one system is down, it adversely impacts the entire workflow. Also, addition of new modules becomes complicated.
Now, let us take a look at the same use case using Event Driven Architecture.
Creation of a patient record generates an event, say 'PATIENT-CREATED'.
There could be multiple consumers for this event. Two consumers consume this event and act accordingly as shown below:
These two consumers allocate a doctor; allocate a ward room respectively, upon consuming this event.
In this architecture, consumers and producers do not know each other. A message is placed on an event bus, with the message having supporting data for the event created.
For example, in the above example, the message could contain a patient_Id, the type of disease etc.
If the data is huge, we can place a correlation Id of the actual data and the consumer has to use another API call to retrieve the data. Once the event is consumed, the consumer can place another event (for example, DOCTOR-ALLOCATED), on the event bus, which would be subsequently consumed by other consumers.
Thus, events indicate 'State Changes' of a system and trigger other events. This pattern leads to a highly scalable loosely coupled architecture.
A mature Service Oriented Architecture uses EDA to achieve high degree of loose coupling.
Challenges of EDA:
Error handling:
If a consumer of an event is down, the message might have to be consumed again when the system is up again and back online.
We need a mechanism to play back events. For this to happen, we need to maintain event logs and a robust mechanism to play back events. Also, if an event is played again, the consumers which have successfully consumed the event should not process it again. For example, if ‘ALLOCATE-DOCTOR’ event failed and the first event is placed on the event bus again, 'ALLOCATE-ROOM' event should not process again. Thus, a lot of care has to be taken care to ensure integrity and consistency.