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.<p>Now when people argue “because decoupling,” I hear, “You don’t get as much notification that you just broke a downstream system.”
I have seen Kafka pulled out by its hairs and replaced with request based architecture.<p>Event driven architecture, to me is itself an antipattern.<p>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.<p>As far as the authors video, while there was some truth in there, it was a little thin, compared to the complexity of these architectures. I believe that even though Kafka acts the part of "dumb pipe", it doesnt stay dumb for long, and the n distributions of Kafka logs in your organization could be 1000x more expensive than a monolithic DB and a monolithic API to maintain.<p>Yes it appears auditable but is it? The big argument for replayability is that unlike an API that falls over theres no data loss. If you work with Kafka long enough you’ll realize that data loss will become a problem you didnt think you had. You’ll have to hire people to “look into” data loss problems constantly with Kafka. Its just too much infrastructure to even care about.<p>Theres also, something ergonomically wrong with event drive architecture. People dont like it. And it also turns people into robots who are “not responsible” for their product. Theres so much infrastructure to maintain that people just punt everything back to the “enterprise kafka team”.<p>The whole point of microservices was to enable flexibility, smart services and dumb pipes, and effective CI/CD and devops.<p>We are nearing the end of microservices adoption whether it be event or request driven. In mature organizations it seems to me that request driven is winning by a large margin over event driven.<p>It may be counterintuitive, but the time to market of request driven architecture and cost to maintain is way way lower.
Not specifically about event-driven, but the most damaging anti-pattern I would say is microservices.<p>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.<p>This typically causes enormous waste of efficiency and consequently causes applications to be much more complex than they need to be.<p>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.<p>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.<p>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.<p>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.
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.
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.<p>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've found is that the event driven architecture did tend to lead to less abstractions and more leaked internal details. This isn't fundamental (you can treat events like an API) but was related to some details in our implementation (something along the line of CDC).<p>Another problem with distributed systems with persistent queues passing events is that if the consumer falls behind you start developing a lag. Yet another considerations is that the infrastructure to support this tends to have some performance penalties (e.g. going through Kafka with an event ends up being a lot more expensive than an RPC call). Overall it IMO makes for a lot of additional complexity which you may need in some cases, but if you don't then you shouldn't pay the cost.<p>What I've come to realize is that in many ways those systems are equivalent. You can simulate one over the other. If you have an event based system you can send requests as events and then wait for the response event. If you have a request/response system you can simulate events over that.<p>If we look at things like consensus protocols or distributed/persistent queues then obviously we would need some underlying resources (e.g. you might need a database behind your request/response model). So... Semantics. Don't know if others have a similar experience but when one system is mandated people will invent workarounds that end up looking like the other paradigm, which makes things worse.<p>There are things that conceptually fit well with an event driven architecture and then there are things that fit well with a request/response model. I'm guessing most large scale complex distributed apps would be best supporting both models.
I’m starting to get a sad about event driven stuff.<p>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.<p>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”?<p>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?<p>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.
What are people’s thoughts on using event driven architecture in games? Specifically multiplayer games, and massively multiplayer games (MMOrpgs).
Another comment mentions it was helpful, how specifically, were there any tradeoffs, do certain types of games work better?
I always thought it would be an interesting exercise to build an event-based controls system. There's a lot triggering action X based on event A. And actions based on composite events. I never found anyone who had done it.<p>Edit- I should say I never saw one in the wild, quick search found some academic projects <a href="https://scholar.google.com/scholar?q=event-driven+control+system&hl=en&as_sdt=0&as_vis=1&oi=scholart#d=gs_qabs&t=1717895148440&u=%23p%3D2KAKAhWCSPkJ" rel="nofollow">https://scholar.google.com/scholar?q=event-driven+control+sy...</a>
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.
"Event driven architecture ". Mēh!<p>There is no avoiding it when dealing with, erm, events.<p>Events are things that happen that you cannot predict exactly when, where, and what.<p>The user clicked the mouse<p>The wind changed direction<p>Using Events to signal state change from one part of a system to another is a bad idea. Use a function call.<p>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
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.<p>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.
Event-driven architecture should be implemented across complete system (client-be) or be used in a single feature, i.e. it needs to be all or bare minimum, else it's just an absolute mess.
Went in thinking I would find out a few pitfalls for the event-driven app I'm writing...<p>> Commands only have a single consumer. There must be a single consumer. That’s it. They do not use the publish-subscribe pattern.<p>...oops.<p>Now the question is how much (more) time I want to spend on a(nother) rewrite.