Lessons from event driven architecture
I am so tired of these sorts of shallow analyses from people that think their screw-ups are actually caused by EDAs or micro services or whatever. They’re even totally transparent about the fact that they did because they heard cool things but never say “so we sat down to learn about best practices, what the current state of the art is, and considered how our use cases matched the architecture”
They just say “we thought it would be cool so we just started doing it and it sucked - here’s why that’s an inherent problem of the architecture and not in any way related to our behavior”.
Yes. If you take a team of people who build n-tier and hexagonal MVC monolithic apps, and then tell them to build micro services, they’re going to build a bunch of n-tier or hexagonal MVC monolith candidates and eventually end up with a single service that does too much and ultimately becomes the monolith.
Yes. If you take a team that does 100% synchronous HTTP interfaces, SOAP or ReST, and then tell them to build microservices, they’re going to daisy chain those microservices via synchronous HTTP interfaces, and if you tell them to build an EDA they are going to build an EDA that attempt to replicate all of the aspects of their synchronous HTTP interfaces with busy polling loops.
So stop doing that and actually do the hard thing of learning fundamentally different architecture, techniques, technologies, trade offs, best practices, operational patterns, design patterns, and heuristics and principles for managing software. Learning is difficult and humbling. But it sure beats writing ignorant articles like this.
opened to read article
sees ugly-ass AI slop picture
closes immediately
To me, the AI slop is a stamp of quality. A bad one.
I read a bit further. Definitely got the vibe that AI had a hand in editing the prose as well, it felt like half a story and half a pros/cons list. There’s some technical content in there that is salvageable, but as a piece of writing, it holds up to that stamp of quality, IMO
Lots of em-dash usage
Service goes down after emitting an event but before persisting internal state—causing partial failures that are hard to roll back.
Subscribe to an existing event and start processing—no changes to publishers.
Helps track a request across multiple services—even through async events.
We once had a refund service consume OrderCancelled events—but due to a config typo, it ignored 15% of messages.
Takeaway: fire-and-forget works—until someone forgets to monitor.
Use it when the domain fits—fan-out use cases, audit logs, or workflows where latency isn’t critical.combined with other chatgpt-isms like the heavy reliance on lists, yeah safe to say it’s mostly AI generated