Live data from Hacker News

Anti-patterns in event-driven architecture

codeopinion.com

41–50 of 171 posts

Re: Anti-patterns in event-driven architecture

#41
I’m starting to get a sad about event driven stuff.

I’ve used it with a good degree of success in some data pipeline and spark stuff to have stuff automatically kick off, without heinous conditional orchestration logic. I also use evented stuff over channels in a lot of my rust code with great success.

However, echoing the sentiments of some other comments: most articles about event driven stuff seem to be either marketing blogspam or “we tried it and it was awful”. To be honest I look at a lot of those blog posts and about half the time my thoughts are “no wonder that didn’t work out, that’s an insane design” but is that just “you’re-doing-it-wrong-cope”?

Are there success stories out there that just aren’t being written? Is there just no success stories? Is the architecture less forgiving of poor design and this “higher bar of entry” torpedoes a number of projects? Is it more susceptible to “architecture astronauts” which dooms it? Is it actually decent, but requires a somewhat larger mindset-change than most people take to it, leading to half-baked implementations?

I can’t help but feel the underlying design has some kernels of some really good ideas, but the volume of available evidence sort of suggests otherwise.

Re: Anti-patterns in event-driven architecture

#42

Can someone share some long term event driven success stories? Almost everything you see online is written by consultants or brand new, greenfield implementations, curious how long these systems last.

Webhooks? Slack automation? GitHub actions?

Re: Anti-patterns in event-driven architecture

#43
My 2 cents - There is no anti-pattern specific to event driven. It is essentially asynchronous nature. It means you start with understanding the business needs and SLA. Question often comes in my experience is "can they wait?" and what's the risk of dirty data or data fetched with delay ( worst case ). event driven is always about worst case scenario and will it work then.

Re: Anti-patterns in event-driven architecture

#44
"Event driven architecture ". Mēh!

There is no avoiding it when dealing with, erm, events.

Events are things that happen that you cannot predict exactly when, where, and what.

The user clicked the mouse

The wind changed direction

Using Events to signal state change from one part of a system to another is a bad idea. Use a function call.

A rule of thumb is if the producer and the consu,er are in the same system then "Event Driven Architecture " is the anti pattern

Re: Anti-patterns in event-driven architecture

#45

I often hear the argument in favor of event-driven architecture that you can work on one part of a system in isolation without having to consider the other parts, and then I get assigned some task which requires me to consider the entire system operation, now with events that are harder to trace than function calls would have been. Now when people argue “because decoupling,” I hear, “You don’t get as much notificatio…

Integration tests?

...happen too late

Re: Anti-patterns in event-driven architecture

#46
post #44

"Event driven architecture ". Mēh! There is no avoiding it when dealing with, erm, events. Events are things that happen that you cannot predict exactly when, where, and what. The user clicked the mouse The wind changed direction Using Events to signal state change from one part of a system to another is a bad idea. Use a function call. A rule of thumb is if the producer and the consu,er are in the same system then "…

What if one event should trigger many actions?

Re: Anti-patterns in event-driven architecture

#47

I often hear the argument in favor of event-driven architecture that you can work on one part of a system in isolation without having to consider the other parts, and then I get assigned some task which requires me to consider the entire system operation, now with events that are harder to trace than function calls would have been. Now when people argue “because decoupling,” I hear, “You don’t get as much notificatio…

Like anything it can be abused and sometimes folks go overboard with turning everything into an event. However, when done right, it is really amazing to work with.

As an event producer as long as you follow reasonable backwards-compatibility best practices then you should be pretty safe from breaking things downstream. As a consumer, follow defensive programming and allow for idempotency in case you need to reprocess an event. Pretty straightforward once you get the hang of things.

Re: Anti-patterns in event-driven architecture

#49

Can someone share some long term event driven success stories? Almost everything you see online is written by consultants or brand new, greenfield implementations, curious how long these systems last.

PostgreSQL. The WAL is an event log, and when you squint at its internal architecture, you’ll see plenty of overlap with distributed event sourcing.

Almost every modern software system. Anything running over the Web is event driven.

Re: Anti-patterns in event-driven architecture

#50
Went in thinking I would find out a few pitfalls for the event-driven app I'm writing...

> Commands only have a single consumer. There must be a single consumer. That’s it. They do not use the publish-subscribe pattern.

...oops.

Now the question is how much (more) time I want to spend on a(nother) rewrite.

Post reply on HN