In scalable deployments, the LlamaIndex Workflow Server may run across multiple pods or instances (e.g., in a Kubernetes environment) to handle high concurrency and fault tolerance.

Currently, the workflow execution context is maintained locally within the pod where the workflow was initiated. As a result, when an external event (such as a human response or webhook) needs to continue a specific workflow run, the client or event source has no deterministic way to know which pod hosts that workflow context.

Proposed Changes:

1. Workflow execution context is persisted in a centralized store accessible by all pods
2. Any pod in the cluster can load and resume workflow execution for a given workflow ID.
3. Optionally, a lightweight coordination or locking mechanism (e.g., via leader election or distributed locks) ensures safe concurrent access.