15

Lessons from event driven architecture

you are viewing a single comment's thread
view the rest of the comments
[-] Sconrad122@lemmy.world 5 points 14 hours ago

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

[-] sus@programming.dev 3 points 12 hours ago* (last edited 12 hours ago)

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

this post was submitted on 17 May 2025
15 points (77.8% liked)

Programming

20211 readers
523 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

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 !webdev@programming.dev



founded 2 years ago
MODERATORS