Live data from Hacker News

Ask HN: Has anyone fully embraced an event-driven architecture?

news.ycombinator.com

91–100 of 173 posts

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#91

There's no such architecture, much like there's no "MVC architecture" or "CQRS architecture". These are patterns that should be used specifically in time and space where and when pros outweigh cons. Anyone calling themselves an architect, or an engineer, or even just a "good developer" would acknowledge that interaction patterns and concepts are contextual, not general idioms at the project or system level. Speaking…

I suppose it all depends on your definition of the word architecture. Erlang and Elixir are instantiations of the actor model, which is fundamentally an event driven architecture. It is universally the way that state and side effects are handled in those languages.

I touch on it a little bit in another comment: https://news.ycombinator.com/item?id=28047306

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#92
post #72

I'm guessing the OP meant event driven with persistent events. If the events exist only at runtime then a lot of burden related to schema evolution disappears. We tried this approach a couple of times with mixed results. In one case, for a new component with strict DDD modeling - it was a boom to productivity. In others , preexisting once we never got to realize the gains, invested quite a bit , not sure if we ever g…

You are right, that's what I was referring to. I have seen DDD working sufficiently well for some use-cases but issues started appearing when the business redefined what the domains are and how the org is structured. I guess there is not a single straight-forward solution to this.

I'm not sure what properties of the system you assign to the DDD label, but in my experience DDD just means you put the domain first. It's all the Event Sourcing and CQRS baggage which gets lumped together with DDD and adds heaps of non-essential complexity.

If the understanding of the domain changes, you change the code - there's no way around that.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#93
post #74

Earlier quoted context omitted.

> Have a plan for building pipelines a->b->c->d. also have a plan for fan out a->b & a->c & a->d How does that look like? Do you mean to learn how this is done with the CI of choice, create helper functions or are there concrete steps that you would recommend? I'm new to this and would appreciate any feedback.

Let's assume a has a time constraint, and needs to start shoveling bytes back to the client in 30ms. In the pipeline case, a probably only has visibility to b, each service in the chain has ~7ms to provide its response. In the fan out case, a is aware of b c and d, they can each take 25ms or more and a can still meet its deadline. The way a sets its timeouts will vary depending on what's happening downstream. This is…

Ohh you talk about call pipelines, I totally missed the point. You are talking about time-constrained systems where an answer in the timeframe is required, right? Otherwise the timeout does not make sense, or would you do such precise timeouts even in non-time-constrained systems?

Anyway, seems to make sense to plan for this timing-wise. Allows addressing and seeing performance bottlenecks. Thank you for spelling it out for me!

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#96
post #61

Earlier quoted context omitted.

I fully agree with this, also that's still quite common in the embedded world. The user presses a button which sets a hardware event flag. CPU wakes up from sleep, checks all event flags, handles them, clears the interrupt bits and goes back to sleep. But using events like this requires a very tight integration between event producer and consumer, so I don't think this will translate well to distributed systems or mi…

There is an example where highly distributed, event-driven systems are used. Everyday we are using them. It the cars. In a car there are many distributed ECUs(1) that communicate in an event driven system. It was tried to use cyclic communication. But all those attempts failed in the long run. Because cyclic communication would required that all the independent ECUs are synced to each other, which is a very hard prob…

Automotive ECUs use cyclic communication and are event driven. ECUs send their signals over CAN at a defined message rate, regardless of whether the state has changed. Other ECUs set up their hardware to monitor the signals they care about, and trigger a hardware interrupt when the signal is received.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#97
I did at an old company.

It was great for certain use cases, bad for others. The architecture made it so it took days to do simple features like adding a sortable column.

Having to deal with that made it the worst job I've ever had. It would take 700 lines of code involving two separate systems and 70 hours to to do tasks that would normally take two hours. I felt a lot of pressure because previously simple tasks would take so long.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#98
I've worked at a company that has launched at least one product where back-end was entirely event-sourced.

Apart from using event sourcing and CQRS, they take DDD very seriously.

They use a self-made open source framework, which has very good JavaDocs. https://github.com/SpineEventEngine/

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#99
post #98

I've worked at a company that has launched at least one product where back-end was entirely event-sourced. Apart from using event sourcing and CQRS, they take DDD very seriously. They use a self-made open source framework, which has very good JavaDocs. https://github.com/SpineEventEngine/

Event sourcing and event driven are two different things.

Re: Ask HN: Has anyone fully embraced an event-driven architecture?

#100
post #21

>"fully embraced" "fully embraces" / commits - not a very wise thing to do. Event driven arch is one of many tools at your disposal. It is awesome for some things and not so much for others. You can't use single tool / approach for everything and expect best results.

I disagree. There are incompatible design disciplines and architectures.

100% functional code is a lot better than 99% functional. 99% functional is a mess. 100% functional gives strong guarantees.

You can split up code horizontally (MVC), vertically ("apps"), but of you mix the two, you get a mess.

I am working on a system which is 100% event-driven, and it works well in the context of this system, which is primarily about realtime data analytics. There are systems I'd build without any event-driven code either. There are hybrid systems too.

There are architectures which are compatible (e.g. structured and OO), but many just aren't. Event-driven is one of those things which adds a lot of complexity to any system. Fully-embraced, that can pay dividends. A little here a little there and you have most of the cost and little upside.

Post reply on HN