Ask HN: When should event-driven architecture be avoided?

#1

Post by reisr3 » Fri, Feb 04, 2022, 12:40 PM UTC

There are plenty of good resources for how to do domain-driven design, microservices, cloud functions, and event-driven architecture. I understand why these paradigms are useful for rapidly scaling an application. Queueing, the ability to adjust resources per service, and enabling separate teams to build their microservice differently.

However, they also add quite a bit of complexity. Using pub/sub breaks execution context, cloud functions are difficult to debug/test/develop locally, etc. I'm having trouble finding quality dissenting opinions online around this topic. Most resources I've found are geared towards how to implement these technologies properly.

In what scenarios would you NOT recommend event-driven architecture?

Re: Ask HN: When should event-driven architecture be avoided?

#2

Post by osivertsson » Fri, Feb 04, 2022, 12:50 PM UTC

The customer couldn’t care less, so if you can deliver without all that complexity congrats!

That means you either have time to focus more on your customers, and therefore win more business, or you just take home more money if it is fixed-income contract work.

I consider companies that add complexity just because BigTechCo does more interested in playing or pretending to be on a path towards success than to actually be.

Re: Ask HN: When should event-driven architecture be avoided?

#3

Post by diatone » Fri, Feb 04, 2022, 1:29 PM UTC

No concurrency? No events. No more than a single team running a single service (even a monolith)? No events. Not dealing with asynchronous 3rd party APIs (eg: webhooks)? No events. Not dealing with arbitrarily many hosts/processes/tasks/objects communicating with each other, potentially asynchronously? No events. Not streaming? No events.

Re: Ask HN: When should event-driven architecture be avoided?

#4

Post by sfrensch » Fri, Feb 04, 2022, 1:32 PM UTC

I think the move to events makes sense once you want to start decoupling systems, so there is a scale/complexity aspect to it. Situations where you would steer clear of events, would be those where you don't care to have the benefit of decoupling.

As an example, imagine a small system where a user changes their email address. In the beginning you might only have one action "update database". As the system grows, maybe new teams start to add new features triggered from that event, say "send confirmation email", "calculate fraud score", "send new email to marketing vendor". You could just go and call all those APIs, but at some point you want to emit a "change email event" and just let the other systems do with it what they will.

Re: Ask HN: When should event-driven architecture be avoided?

#5

Post by sorokod » Fri, Feb 04, 2022, 1:44 PM UTC

When unrestricted, event driven systems don't have a well defined overall state or consistency.

Avoid if you have rules that depend on a system "state"

Having said that, toy systems aside, almost all systems require reasoning of their overall state at some point, so in general - avoid.

Re: Ask HN: When should event-driven architecture be avoided?

#6

Post by hussainbilal » Fri, Feb 04, 2022, 2:08 PM UTC

diatone wrote: post #3

No concurrency? No events. No more than a single team running a single service (even a monolith)? No events. Not dealing with asynchronous 3rd party APIs (eg: webhooks)? No events. Not dealing with arbitrarily many hosts/processes/tasks/objects communicating with each other, potentially asynchronously? No events. Not streaming? No events.

Basically this. Theoretically, event-driven architecture within a single machine is just re-inventing pi-calculus (i.e. sending values on channels)

So I would imagine anything single-threaded would not require it.

Though admittedly, the only modern application or program that I can think of that would be single-threaded is a CLI command

Re: Ask HN: When should event-driven architecture be avoided?

#7

Post by sorokod » Fri, Feb 04, 2022, 2:15 PM UTC

sfrensch wrote: post #4

I think the move to events makes sense once you want to start decoupling systems, so there is a scale/complexity aspect to it. Situations where you would steer clear of events, would be those where you don't care to have the benefit of decoupling. As an example, imagine a small system where a user changes their email address. In the beginning you might only have one action "update database". As the system grows, mayb…

I often see this sort of argument and disagree. The complexity is still there but instead of being someone's problem, it's owned by no one.

Re: Ask HN: When should event-driven architecture be avoided?

#8

Post by pestatije » Fri, Feb 04, 2022, 2:23 PM UTC

It shouldn´t. The way to proceed is to overcome its drawbacks. The world is async, do not fight it.

Re: Ask HN: When should event-driven architecture be avoided?

#9

Post by busterarm » Fri, Feb 04, 2022, 3:06 PM UTC

sorokod wrote: post #7

sfrensch wrote: post #4

I think the move to events makes sense once you want to start decoupling systems, so there is a scale/complexity aspect to it. Situations where you would steer clear of events, would be those where you don't care to have the benefit of decoupling. As an example, imagine a small system where a user changes their email address. In the beginning you might only have one action "update database". As the system grows, mayb…

I often see this sort of argument and disagree. The complexity is still there but instead of being someone's problem, it's owned by no one.

That's an organizational problem, rather than a software architecture problem.

Refer to the first 3 bullet points of the Bezos Mandate.

Re: Ask HN: When should event-driven architecture be avoided?

#10

Post by sorokod » Fri, Feb 04, 2022, 3:08 PM UTC

busterarm wrote: post #9

sorokod wrote: post #7

Earlier quoted context omitted.

I often see this sort of argument and disagree. The complexity is still there but instead of being someone's problem, it's owned by no one.

That's an organizational problem, rather than a software architecture problem. Refer to the first 3 bullet points of the Bezos Mandate.

Depends on your definition of "organisational" but note that it is the architecture that converts one to the other.

In fact it is this that makes event driven so attractive, rather the solving a difficult problem right now, someone will need to sort out the mess later.