Leaving aside the conflict of interest here ("EDA bad, workflows good, buy DBOS workflows"), this is a significant straw man. The author more or less picked the worst example of event-driven architecture, then says, "See? It's bad."
The flow of reserve item -> check credit -> process payment -> fulfill order is actually a pretty synchronous process. There's no reason to make that event-driven unless you actually need it.
Should people reach for event-driven first? No, almost certainly not. Is this something that should be event-driven? Not as presented.
But if you imagine that the process becomes "process payment -> [5 other things]," such as fulfilling order, sending receipts, updating analytics, initiating fraud detection... those are all things that should be done in parallel and none of them need to know about the others, nor does the payments system need to know about them. _That_ is a better use-case for EDA that justifies the additional complexity and cost that the author is warning about.
I used a simple event architecture to manage federated identity migration and setup. When an existing user in our internal auth system was migrated to SSO, the identity manager sent a message that fanned out to the internal systems that used legacy auth to tell them to associate the old legacy user info with the new federated identity. If a system had a problem creating the association, it would put a failure message on the bus that we later processed depending on the failure type.
Leaving aside the conflict of interest here ("EDA bad, workflows good, buy DBOS workflows"), this is a significant straw man. The author more or less picked the worst example of event-driven architecture, then says, "See? It's bad."
The flow of reserve item -> check credit -> process payment -> fulfill order is actually a pretty synchronous process. There's no reason to make that event-driven unless you actually need it.
Should people reach for event-driven first? No, almost certainly not. Is this something that should be event-driven? Not as presented.
But if you imagine that the process becomes "process payment -> [5 other things]," such as fulfilling order, sending receipts, updating analytics, initiating fraud detection... those are all things that should be done in parallel and none of them need to know about the others, nor does the payments system need to know about them. _That_ is a better use-case for EDA that justifies the additional complexity and cost that the author is warning about.
I used a simple event architecture to manage federated identity migration and setup. When an existing user in our internal auth system was migrated to SSO, the identity manager sent a message that fanned out to the internal systems that used legacy auth to tell them to associate the old legacy user info with the new federated identity. If a system had a problem creating the association, it would put a failure message on the bus that we later processed depending on the failure type.