Programming

20228 readers

187 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] 8 points 2 days ago (1 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 19 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 17 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.