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

Anti-patterns in event-driven architecture

codeopinion.com

Post reply on HN
Print view View original

121–130 of 171 posts

Re: Anti-patterns in event-driven architecture

#121

Post by friendzis »

lmm wrote: post #89
mrkeen wrote: post #71

Earlier quoted context omitted.

> now with events that are harder to trace than function calls would have been I don't know how this could be true. Events are things - nouns which can be backed-up, replicated, stored, queried, rendered, indexed and searched over.

There's no "find usages" for events, and it becomes harder to find out why something didn't happen. A function call can't simply "not return" - in the worst case you get an exception, or a stuck thread in the caller that will show up in a stack dump. But downstream event processing can very easily just not happen, for one of many different reasons, and out-of-the-box it's often difficult to investigate.

> A function call can't simply "not return"

Remember "callback hell"? Assumption that a function call returns after running to completion requires rather specific synchronous cascading architecture, which WILL break in multithreaded code. Most of the multithreaded function calls will set a flag in shared memory and return early, expecting caller to poll.

If your API is based on single entry-point `invokeMethod(callee, method)` it is equally untraceable to event entry point `fireEvent(producer, event)`.

Re: Anti-patterns in event-driven architecture

#122

Post by buster »

pudwallabee wrote: post #22

I have seen Kafka pulled out by its hairs and replaced with request based architecture. Event driven architecture, to me is itself an antipattern. It seems like a replacement for batch processing. Replayable messages are AWESOME. Until you encounter the complexity for a system to actually replay them consistently. As far as the authors video, while there was some truth in there, it was a little thin, compared to the…

I think the problem here is Kafka and not event driven architecture. I am a strong proponent of not using Kafka for events. It's wrong 90% of the time and for the other 10% you can find better solutions.

Also, people need to understand that "event driven" has nothing to do with "event sourcing". Just don't keep all the events until eternity, because you can (and because some people think you should because "kafka").

Re: Anti-patterns in event-driven architecture

#123

Post by friendzis »

zdragnar wrote: post #81
Osiris wrote: post #58

Earlier quoted context omitted.

What I like about event driven is that you don't even need to know if anyone is listening to or cares about your event. And as a consumer, many independent tasks can be triggered by the same event. I'm working on a system right now and because of events, it's very easy for me to write a handler for when a certain type of record is created in the database. My feature depends on knowing that new record was made so we c…

> you don't even need to know if anyone is listening to or cares about your event. Right up until you need to change something about the event because the business logic it represents has changed. Then you suddenly need to track down all the systems that have been relying on it, including that one that nobody knows anything about and always forgets exists because some guy decided to implement the service in erlang an…

I really dislike this argument, because it puts the duty of managing dependencies and requirements directly on code. This is organizational issue!

First, if your event (or whatever) changes enough that there are inter-component breakages it means engineering requirements must have changed and tracing dependencies of requirements is organizational thing.

Second, you either do trunk based development and constantly break downstream or do leaf based development and have constantly out of date core dependencies. In any case, that's release version management, which is again organizational thing.

Re: Anti-patterns in event-driven architecture

#125

Post by liampulles »

Our system at work is a command driven system. We don't use messages as a source of state, but really just as Async instructions. And we store them which can be useful for retrying, data fixes, and stats.

I feel like a lot of teams out there can probably benefit from this simpler approach - it's probably what a lot of people are doing unwittingly.

Re: Anti-patterns in event-driven architecture

#126

Post by liampulles »

candiddevmike wrote: post #3

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.

Our system is command driven, and works well, but it is because we explicitly have less rigorous demands on the messages and the messages don't cross team boundaries. My past experience also makes me wary of event driven systems.

Re: Anti-patterns in event-driven architecture

#127

Post by mattacular »

pyrale wrote: post #119
majormajor wrote: post #105

Earlier quoted context omitted.

> As an event producer as long as you follow reasonable backwards-compatibility best practices then you should be pretty safe from breaking things downstream. That can protect you from "downstream can't even read the message anymore" but it doesn't help you with the much more common "downstream isn't doing the right thing with the message anymore" problem. Schema evolution is kinda like schema'd RPC calls vs plain JS…

Data consumers in unknown teams is a nightmare regardless of the architecture. Events sent for readership you can’t control are ideally of the type «x changed», and the consumer must then fetch data on the relevant endpoint. That or the company must have serious versioning policies.

What's the benefit of using an asynchronous event driven system if you can't process any of those events without performing a synchronous query back on the same provider for all of the necessary data?

Re: Anti-patterns in event-driven architecture

#128

Post by blowski »

chenster wrote: post #106
blowski wrote: post #10

Earlier quoted context omitted.

I was the lead developer on one for an insurance company a few years back, and it’s still in active use. Insurance is a heavily regulated domain, where an audit trail is more important than performance. There was a natural pattern for it to follow, as we were mapping a stable industry standard. I also tried doing it in a property setting, where profit margins were tight. The effort needed wasn’t worth the cost, and c…

What did you mean traditional crud as oppose to event-driven arch? How is it relevant to the subject in dicussion?

Event-driven: At runtime, the client tells the system what has happened, the system stores the event and is configured in advance for how to react to it.

CRUD: Imperative. Client tells us to create/update a specific entity with some data.

Re: Anti-patterns in event-driven architecture

#129

Post by bux93 »

YZF wrote: post #84

I've worked in a large company where some variation of event driven architecture was used everywhere and treated as the word of G-d. Fairly successfully. Mostly in applications that ran on a single machine. I've ended up in a lot of arguments about this while we were building larger distributed systems because I've come from a more request/response oriented message passing architectures. I.e. more synchronous. What I…

Every synchronous call is, in fact, asynchronous. We just hide it on the stack, in the return address, in the TCP connection etc. No call is really blocking anymore, the OS or the CPU will run some other thread. People who insist that things are simpler in a synchronous model are just ignoring the actual mechanics. Which is fine, that's just abstraction.

Re: Anti-patterns in event-driven architecture

#130

Post by onetimeuse92304 »

Not specifically about event-driven, but the most damaging anti-pattern I would say is microservices.

In pretty much all projects I worked with in recent years, people chop up the functionality into small separate services and have the events be serialised, sent over the network and deserialised on the other side.

This typically causes enormous waste of efficiency and consequently causes applications to be much more complex than they need to be.

I have many times worked with apps which occupied huge server farms when in reality the business logic would be fine to run on a single node if just structured correctly.

Add to that the amount of technology developers need to learn when they join the project or the amount of complexity they have to grasp to be able to be productive. Or the overhead of introducing a change to a complex project.

And the funniest of all, people spending significant portion of the project resources trying to improve the performance of a collection of slow nanoservices without ever realising that the main culprit is that the event processing spends 99.9% of the time being serialised, deserialised, in various buffers or somewhere in transit which could be easily avoided if the communication was a simple function call.

Now, I am not saying microservices is a useless pattern. But it is so abused that it might just as well be. I think most projects would be happier if the people simply never heard about the concept of microservices and instead spent some time trying to figure how to build a correctly modularised monolithic application first, before they needed to find something more complex.

Post reply on HN