Sounds very similar to "sagas" in the Domain Driven Design/Event Sourcing space. The general advice I have here is to not use event-sourcing/event-driven archi

Sounds very similar to "sagas" in the Domain Driven Design/Event Sourcing space. The general advice I have here is to not use event-sourcing/event-driven architectures for everything. Use it where the domain maps well to a process that happens over time. An order system is the canonical example. That doesn't mean your products, customers, accounts, etc all need to be event sourced/event driven as well. It will be fine leaving those managed by a CRUD architecture. Keep things as simple as possible (but no more simple). There are plenty of areas where an event-driven/event-sourced architecture will make things easier and others where it will make things way harder. I find if you need a lot of sagas/orchestration... you're delving into the latter. (I make the distinction between event sourced and event driven as this: the former is about persisting and deriving state; the latter is about communicating changes to other systems).