Event Driven Architecture

Nuwan Zen
2 min readJun 27, 2021

Event Driven Architecture has a very close relationship to Message Driven Architecture. Let’s compare point to point traditional approach vs message driven vs Event driven architecture with an example,

Let’s consider air line system where if a flight is delayed it will update the parties to do tasks like

  • informing the passengers
  • booking hotels for night stay
  • scheduling another flight
  • issuing tokens for snacks

Classic programming models

This is the traditional approach where method a of application a directly make a call to method b of application b. In this example main system notifying flight delay call all those services synchronously, that is until the task is completed system will hold.

Disadvantages are if a down system has an error main system also will fail. That is tight coupling. To solve this issue asynchronous systems are introduced which users messages as communication medium.

Asynchronous (Message Driven)

Asynchronous systems requires message broker to hold messages. Instead of directly calling the other system this approach simply sends a message to a messaging queue. Message will be the same message we communicating to down stream.

So architecture wise we will not see a big change other than asynchronous. Sending the message looks very much like a function call where api knows what is calling, expects a certain outcome and will wait for that result.

Event Driven

In this approach events are created once a task is completed. In our example flight system will simply update the system as delayed and the other systems will read this status and then act on it.

The thing to note is main system will not be responsible for executing tasks, sub systems will be responsible for the tasks to complete.

Big advantage of this is main system doesn’t target any subsystem so the event it publishing is more generalized and can be consumed by other systems as well. It will make integrating new systems very easy.

Events are state not a message to communicate so another party should read this event.

It will update there is a event has happened but it doesn’t expect anything else to happen due to this event as event is a just a state. On the other hand message is a command to execute. So in a message driven system still the producer is the one who sends the commands to the consumer.

In a event driven system isn’t asked to do any stuff, consumer will check the event list periodically and complete the next stage.

Conclusion

In Message driven approach, producer is the responsible person for the whole process, but in event driven system producer just completes his work updates the board that he has completed his work, he not going tell the others what next should be done, instead consumer needs act based on this status.x

--

--

Nuwan Zen

Sometimes A software Engineer, sometimes a support engineer, sometimes a devops engineer, sometimes a cloud engineer :D That’s how the this life goes!