What happened
Uber’s November 11, 2026 engineering announcement introduces Shard Manager as a general-purpose, open-source sharding service in the cadence-workflow GitHub organization. Its first production application at Uber is Cadence Matching, which routes workflow and activity tasks to workers, with task lists serving as shards. Uber says the integration model is intended to support other sharded services as well.
The service separates ownership decisions from application logic. Applications remain responsible for processing shards and defining meaningful load measurements; Shard Manager coordinates placement and ownership. Executors process assigned shards and periodically report status and load. Spectators need to discover ownership and route requests, and receive ownership updates that they can cache. A service can take both roles. Shard Manager is not in the primary request path: spectators route directly to the relevant executor. The system uses Go, gRPC and etcd for persistence and leader election, with one elected leader per namespace. Uber says it plans to make etcd optional and remove that infrastructure dependency.
Uber contrasts this with Cadence’s previous use of Ringpop, a consistent-hashing library. Hosts independently derived ownership from cluster membership, distributing shard counts without accounting for differing shard workloads. Inconsistent views of membership also made ownership harder to diagnose, while changing placement required changing cluster membership. Uber says that without autoscaling, operators repeatedly added or removed hosts; with autoscaling, the system could add hosts until utilization targets were met while leaving capacity underused.
The balancing algorithm aims to avoid both persistent overload and unnecessary movement. It uses smoothed load measurements, upper and lower thresholds, a movement budget, and a cooldown after changes. Uber’s example compares a host with shards of load 100 and 60 against another host at 40: moving the 60-load shard brings both hosts to 100, whereas moving the largest shard produces a less balanced result. Operators can use the smctl CLI to inspect shard ownership, list executors, drain a host, or drain and restore individual shards.
For a production cluster, Uber reports that CPU utilization on the hottest Matching host fell by 38%, and the average hottest-to-average host utilization ratio declined from about 2.3× to 1.4×. The company says the improved distribution allows the same traffic to run on about 40% fewer hosts. In 24 workload snapshots compared with a constraint solver, Shard Manager’s load spread was within 5% of the solver’s optimal result in 23 snapshots and within 1% in 14. Uber identifies Cadence History as the next planned integration; it says moving those shards is more complex.
What the archive adds
New Runtime’s earlier coverage, “Ensuring Similar Computational Resources to Stateful Workloads Running on a Diverse Server Fleet” (October 18, 2026), described resource allocation that targets normalized compute performance across heterogeneous hosts. Shard Manager is a new event on the same broader systems concern: this release adds explicit, load-aware shard placement and production measurements, rather than restating that earlier scheduling work.
Trend signal
This supports agent economics moves to completed work only weakly: the underlying idea of measuring real workload rather than a proxy is relevant, but Uber’s announcement concerns general distributed-systems capacity, not agent task economics. This does not yet materially advance a pattern New Runtime tracks.
Why it matters
Hash-based assignment is simple, but equal shard counts do not guarantee equal work. When a small number of shards dominate traffic, the hottest host can determine the size of the whole cluster. Explicit ownership gives operators a record they can inspect and a way to drain work without manipulating membership; application-reported load gives the placement controller a signal that shard counts cannot provide.
Uber’s reported reductions are specific to its Matching deployment and depend on useful load measurements, but the architecture separates concerns in a reusable way: the application defines and executes work, while a control-plane service coordinates ownership. Teams evaluating a similar design should account for the cost of operating that service and the risk of excessive movement, then test whether their own workload signal predicts actual resource pressure.
Limits and uncertainty
The reported CPU, host-count and solver-comparison results come from Uber’s deployment and workload snapshots; the announcement does not establish that another service or traffic shape will see the same gains. Placement quality depends on applications reporting measurements that reflect real work, and the algorithm deliberately trades faster convergence for fewer shard moves. The announcement identifies Cadence History as a planned integration, not a completed one. Independent measurements of the open-source implementation and its operating costs are not established by Uber’s results.
Reader takeaway
Shard counts are not a reliable proxy for workload balance. Shard Manager makes ownership explicit and uses application-reported load to move work, while keeping routing and processing out of the control plane. The useful test for another team is whether shard-level load can be measured well enough to justify a separate placement service and its operational overhead.
Open question
How does Shard Manager perform across services with different load signals and shard-movement costs?