0

Is it common for event-driven architectures to have components in the same application that send events/commands to themselves ? (take a look at the below picture).

I have this weird scenario at work and it doesn't seem quite right. Example of events/commands that this component sends to itself: FILE_ARRIVED , PROCESS_FILE, FILE_PROCESSED

I'm obviously not an expert in event driven architectures. Actually, this is the first "wanna be" event-driven system for which I provide my services. But I would really appreciate to hear your thoughts about this. Thank you.

component in the same application

Kick
  • 13
  • 1
  • 3

1 Answers1

0

Disclaimer first: Without knowing the details of your application domain and how the service boundaries are cut we could not give you any advice on your specific situation. It is possible that the service boundaries were chosen poorly, for example, but there may also be good reasons why the authors have chosen that design.

There are two general things to consider here:

  1. In general a component using an event driven approach internally would not be an uncommon pattern- While event driven architectures are most famous for solving the communication problem in distributed systems with microservices, they have been used in different forms in all kinds of software architectures. Some examples are callback registrations and/or message pipes/queues for inter-process communication.

  2. Which brings us to point number two - When is the network communication overhead for using an external event bus justified? Primarily when the messages/events are consumed by external components, of course, but another reason could be when the event bus is used as a form of persistence for an otherwise transient component. For example in cases where messages/events are not allowed to be lost, e.g. in a crash, hardware failure, etc., there is incentive to send them to a system with persistence as soon as possible.

Oswin Noetzelmann
  • 9,166
  • 1
  • 33
  • 46