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

1. 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.
2. Don't use asynchronous events for sequential processes. How did they not foresee this problem before ever writing a line of code?
3. 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.
4. 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.