> What would happen if the orchestrator was unable to update the remote shared cache outbox after a local exception/rolled back transaction

To be sure, I understand your question, you are referring to the following scenario:

- Start global transaction

- Create shared cache entry

- Add events to the shared cache

- Local transaction fails

- Orchestrators starts rolling back local transaction

- Attempts to delete shared cache entry <-- THIS ONE FAILS

To ensure we don't have stale events in the cache, I would add a TTL, which is configurable for each job (such that you can have long-living events). So in case the orchestrator fails to delete the cache entry, they would be invalidated at some point by exceeding its TTL.