[Osiris]

What I like about event driven is that you don't even need to know if anyone is listening to or cares about your event.

And as a consumer, many independent tasks can be triggered by the same event.

I'm working on a system right now and because of events, it's very easy for me to write a handler for when a certain type of record is created in the database. My feature depends on knowing that new record was made so we can send some emails and do other things.

The people that wrote the code that creates the record, didn't have to do anything to support the feature.

But I agree that it's not the right solution for every problem. But there are certain problems it solves really well.

[zdragnar]

> you don't even need to know if anyone is listening to or cares about your event.

Right up until you need to change something about the event because the business logic it represents has changed. Then you suddenly need to track down all the systems that have been relying on it, including that one that nobody knows anything about and always forgets exists because some guy decided to implement the service in erlang and nobody who ever touched it even works at the company anymore.

[sharlos201068]

How is that any different for an API-driven architecture? You'd need to track down all consumers of your API you're wanting to make a breaking change to.

[friendzis]

I really dislike this argument, because it puts the duty of managing dependencies and requirements directly on code. This is organizational issue!

First, if your event (or whatever) changes enough that there are inter-component breakages it means engineering requirements must have changed and tracing dependencies of requirements is organizational thing.

Second, you either do trunk based development and constantly break downstream or do leaf based development and have constantly out of date core dependencies. In any case, that's release version management, which is again organizational thing.