Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

11–18 of 18 posts

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

#11

Post by busterarm »

sorokod wrote: post #5

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.

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

#12

Post by slively »

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.

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

#13

Post by dc-programmer »

busterarm wrote: post #11
sorokod wrote: post #5

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

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

#14

Post by busterarm »

dc-programmer wrote: post #13
busterarm wrote: post #11

Earlier quoted context omitted.

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 thi…

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.

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

#15

Post by dc-programmer »

busterarm wrote: post #14
dc-programmer wrote: post #13

Earlier quoted context omitted.

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 thi…

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?

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

#17

Post by busterarm »

dc-programmer wrote: post #15
busterarm wrote: post #14

Earlier quoted context omitted.

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.

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

#18

Post by bjourne »

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.

Post reply on HN