Lessons from event driven architecture

  • rowdyrockets@lemm.ee
    link
    fedilink
    arrow-up
    11
    arrow-down
    1
    ·
    21 hours ago

    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.

    • Sconrad122@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      21 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
        link
        fedilink
        arrow-up
        3
        ·
        edit-2
        19 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