Programming

20228 readers

191 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

Everything Started with the Promise of Loosely Coupled Systems (newsletter.systemdesignclassroom.com)

submitted 2 days ago by [email protected] to c/programming

7 comments fedilink hide all child comments

Lessons from event driven architecture

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 13 points 2 days ago (3 children)

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.

[–] [email protected] 8 points 2 days ago (2 children)

Glad I'm not the only one who read the article and thought it sounded like failures of research and planning more than anything.

There are different event system with different guarantees. If the guarantee is "at least one delivery" that means you have to deal with duplicate messages. If it guarantees "At most one delivery" then you have to deal with missing messages.
Don't use asynchronous events for sequential processes. How did they not foresee this problem before ever writing a line of code?
This is just my strong opinion, but unless you know exactly what the fuck you're doing I would either emit events or ingest events. Not both.
What is the event driven design trying to solve? If the answer to this doesn't involve throughput limitations or disparate systems responding separately (completely isolated from one another) to a single event, what the fuck are you even doing?

And last I'm going to bring up a pet peeve; maybe it's related or maybe I'm just projecting. Agile doesn't fucking mean make the story work in a sprint and think about nothing else. I see far too many developers and PMs both with the attitude of just making it work and iterating/improving will happen later. What you end up with is architecture by accident, which is exactly what this sounds like. You're going to constantly have sprints redoing a bunch of work when your architecture starts to coalesce and nothing fits, or you're going to have spaghetti with code duplication and awkward coupling everywhere.

Agile is great, but don't fuck it up by thinking vibe architecting is a thing. Plan shit, create standards, enforce them. Acceptance criteria isn't the end all be all of story success.

I've seen some shit.

[–] tyler 1 points 16 hours ago (1 children)

I’d love to hear more about your point 3. How are you ingesting events and then responding back without emitting your own events?

[–] [email protected] 1 points 15 hours ago

I don't want to pretend this is some kind of gospel or anything, but the way I see it messaging frameworks are meant to broadcast to listeners — one directional and 1:n. And to use a radio analogy, the radio broadcasts music, but you don't have to update them that you've heard a song. And if you do need to send something back, you pick up the phone and make a (rest) call.

I think if you need bidirectional communication between systems, they are coupled in a way that just makes sense to use rest calls (even those are almost always going to be one client, one service, not each one calling the other, right?). If you've got an architecture idea I'd be happy to entertain it. There are probably whole industries with use cases I've never encountered before. But as far as I can tell, using an event framework was never intended for bidirectional communication.

That being said, I can imagine an application that listens to a sales stream and identifies inventory that needs to be shipped from a warehouse, and then the warehouse broadcasts a stream of shipping data. But even in that case, I feel like the listener that generates loading orders and the broadcaster that updates the states of outbound shipments would be two separate services.