Ask HN: When should event-driven architecture be avoided? | Hacker News Reader

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

23 pointsreisr317 comments

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?

View on HN

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

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.

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.

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.

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.

This is just software engineers failing to have taken classic basic engineering courses during their education. These are basic problems that control systems deal with and you have things like PID that to other engineering disciplines are obvious.

The amount of times I've seen software clearly want to have a form of PID controller and fail to realize that such a thing even exists are countless.

Do you have any recommendations for resources that map control theory to web services? I find the idea really interesting. I have two questions though

How well do controllers work with non-numerical inputs? I would assume the usual use cases involve numerical data from sensors.

Does it work well with applications where the importance of availability supersedes consistency? When I hear controller, I can’t help but think single point of failure

You might want to apply it to the scaling of web services rather than the fine details of the application itself. I think you would want to focus on the areas where you can reduce your variables to simple numerics.

That does make sense, but isn’t that what container orchestration services do for you?

Not very effectively yet, in my experience. Also, "throw more compute at it" is much simpler in complexity to something like PID. We don't have good orchestration yet for automating changes of multiple variables.

/s orchestrating workloads on 10^5 hosts.

Event-driven models work great when you have problems that can be modeled as series or sets of reply/response events or cycles. It does not work great when your problem is stateful, when minimum latency is important, when your problem is essentially one reply/response cycle or naturally sequential. The internals of a 3d engine should probably not be event-driven (the api might be, however). A program for listing files in a directory should also probably not be event-driven. Nor a program for computing solutions to differential equations. A text editor definitely should be event-driven.

That said, IME, event-driven architectures are more often than not the right choice for complex software. It's just a very intuitive way to model software.

I tend to think of it the same way I think of moving to an eventually consistent database. You do it when you have to, and as little as possible.

You correctly identified the overhead of these approaches is massive and has implications bigger than the software. The impact on developers cannot be understated.

The approaches you listed are useful, and the dissent I have isn’t so much on the approach, as the timing of when it gets used. Tons of software will never need its benefits and shouldn’t pay the tax ever. Paying the tax before you have to is very rarely worth it in my experience.

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

When doing the necessary communication to solve PDEs numerically on multiple nodes.

Reply on news.ycombinator.com