How Uber Builds Zone-Failure-Resilient OpenSearch Clusters

**Uber** keeps its **OpenSearch** deployments available through a zone outage by combining **OpenSearch**’s built-in **shard allocation** with its own **isolation-group** system. The approach is meant so that when a zone fails, the cluster can still serve queries and accept ingestion rather than losing one or both paths. InfoQ reported the design in a write-up by Claudio Masolo under the title “How Uber Builds Zone-Failure-Resilient OpenSearch Clusters.”

On the technical side, **shard allocation** is the OpenSearch mechanism that places and moves primary and replica shards across nodes so data and serving capacity are spread rather than pinned to a single failure domain. Uber pairs that with **isolation groups** implemented on **Odin**, its container orchestration platform. Isolation groups constrain where workloads and cluster members can land so that related capacity is not co-located in a way that a single zone outage takes out both the live path and its backup.

For engineers who run search or log indexes, the useful idea is not a new product feature but an operational pattern: treat zone failure as a first-class placement problem, not only a failover script problem. Query and ingestion both have to remain viable; keeping only one of them is not enough if producers keep writing while readers stall, or if readers stay up while writers back up. Builders who operate multi-zone clusters can map this to their own orchestrator and allocation awareness instead of assuming a managed default is enough.

Competitively, this sits in the broader pattern of large platforms hardening open-source search infrastructure for multi-zone production rather than treating **OpenSearch** as a single-region black box. Uber’s leverage is control of the orchestration layer (**Odin**) plus native **OpenSearch** allocation, rather than a public, productized multi-zone product story. Peers running Elasticsearch-compatible stacks face the same zone-blast-radius problem; the differentiator is how tightly placement policy is wired into the container platform.

Practical takeaway: if you run **OpenSearch** (or a similar shard-based search store) across zones, audit whether shard allocation awareness and your orchestration isolation rules actually keep both query and ingestion paths multi-zone, or only one of them. What to watch next is whether Uber publishes more detail on how isolation groups interact with allocation under partial zone loss, and how other large operators document the same split between built-in cluster features and custom orchestration policy.