Skip to content

PATTERN Cited by 1 source

Dynamic consistent hashing via service registry

Dynamic consistent hashing via service registry is the pattern of using an existing service registry (already maintained for health checking) as the source of truth for consistent-hash ring membership, eliminating the need for a separate coordination service (ZooKeeper, etcd) or explicit rebalancing protocol when cluster size changes.

Pattern shape

  1. Each instance queries the service registry for the current list of healthy ASG instances.
  2. Instances are maintained in sorted order — all instances see the same ordered list (consistency guarantee).
  3. The hash function findOwnerInstance(aggregator.primaryKey) maps keys to instances based on this sorted list.
  4. When ASG scales up/down, the sorted list updates automatically → the hash function redistributes keys naturally.

Why it works

  • Leverages existing infrastructure — no new coordination service to operate.
  • Consistent hashing provides stability — most keys stay on the same instance during membership changes (only ~1/N keys move).
  • Sorted list ensures consistency — all instances compute the same owner for a given key at the same point in time.
  • No manual intervention — scale events are automatic.

Key insight from Netflix (2026-07-13)

"Leverage existing infrastructure. Our service registry already tracks ASG membership for health checking. Using it as our source of truth gives us dynamic cluster membership for free."

During traffic spikes or live events, new instances immediately receive their share of aggregators. During deployments, aggregators seamlessly shift to healthy instances. No coordination protocol, no manual rebalancing — just automatic redistribution. (Source: sources/2026-07-13-netflix-building-service-topology-at-scale-architecture-challenges)

Trade-offs

  • Eventual consistency in membership — registry updates are not instantaneous; brief windows exist where instances disagree on membership. Acceptable for aggregation (duplicate processing is cheaper than coordination overhead).
  • No bounded-load guarantees — unlike bounded-load consistent hashing, this doesn't prevent hot keys. Netflix solves hot keys separately via patterns/graduated-redistribution-for-skewed-data.

Seen in

Last updated · 585 distilled / 1,765 read