> 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 under

> 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.