Skip to content

PATTERN Cited by 2 sources

Weighted DNS traffic shifting

Weighted DNS traffic shifting uses DNS records with integer weights (e.g. AWS Route 53 weighted records) to split client resolutions between two (or more) backends proportional to the weights. Incrementally change the weights over time to shift traffic at the DNS layer without touching client or server code. Trivial rollback (reverse the weights).

The canonical use cases in this wiki:

  • Cross-substrate service migration — each service cuts from the old substrate to the new one via DNS weights. Figma's ECS→EKS cutovers worked this way.
  • Blue/green service-mesh migration (see patterns/blue-green-service-mesh-migration) — shift traffic from blue mesh to green mesh at the DNS edge when the meshes can't share service discovery.
  • Multi-cluster active-active (see patterns/multi-cluster-active-active-redundancy) — steady-state even-weighting across N clusters, adjusted during cluster-wide operations.

Shape

  1. Publish two (or more) DNS records for the same hostname, one per backend. Each has an integer weight.
  2. Resolvers pick proportionally to weights.
  3. Adjust weights over time (typical migration progression: 1% → 5% → 25% → 50% → 100%).
  4. Monitor business + infrastructure health at each stage; revert by adjusting weights back.

Why it wins for incremental cutovers

  • No client-code changes required. Services using a hostname just resolve differently.
  • Small blast radius per weight change. Compared to a hard-cutover.
  • Reversible. Rollback is a weight change, not a rebuild.
  • Works across environment boundaries — even when the two backends can't share networking (as in blue/green mesh migration).

Tradeoffs

  • Slow propagation. Bounded by DNS TTL, usually seconds to minutes. Not suitable for instantaneous shifts.
  • Client-side caching. Stubborn resolvers / buggy clients may hold stale records longer than TTL. Edge case — mostly harmless for incremental-migration purposes.
  • Not per-request granularity. Each client picks one record at resolution time and uses it until it re-resolves.
  • No session awareness. A user session spanning the cutover might change backend mid-session; OK for stateless services, needs care for stateful ones (sticky sessions, reconnect tolerance).

Alternatives at other layers

  • ALB / application-layer weighted routing — faster propagation, tighter per-request control, scope limited to one ALB.
  • CDN continuous deployment — fastest propagation for CDN-fronted traffic, CloudFront-only.
  • Service-mesh traffic splitting (Istio VirtualService weight, App Mesh Virtual Router weight) — when both old and new sit in the same mesh.

DNS weighting is the environment-independent option: works regardless of whether the two backends are in the same mesh, same cluster, same cloud, same account, or none of those.

Seen in

Last updated · 200 distilled / 1,178 read