PATTERN Cited by 1 source
DNS routing policy selection at CDN scale¶
Problem¶
You're running persistent-connection protocols (gRPC, WebSocket) behind a CDN (CloudFront) with multiple origin load balancers. You need to choose a DNS routing policy for the origin domain. The routing policy choice is architecturally invisible at low scale but determines success or failure at extreme scale.
Context¶
- A CDN fleet has many edge nodes, all resolving the same origin domain.
- Persistent connections accumulate on whichever origin is resolved at connection time and don't naturally redistribute (unlike stateless HTTP).
- Live-event traffic surges go from near-zero to peak in seconds, creating a "thundering herd" of new connections all needing origin resolution simultaneously.
Solution¶
Choose a routing policy that returns multiple IPs per DNS response rather than one:
| Policy | IPs per response | Appropriate for persistent protocols at CDN scale? |
|---|---|---|
| Weighted | 1 | ❌ All edges converge on single origin per TTL |
| Latency | 1 | ❌ Same concentration problem within a region |
| Failover | 1 (primary) | ❌ Active-passive only |
| Multi-Value Answer | Up to 8 | ✅ Immediate distribution across all origins |
Forces / trade-offs¶
- Weighted routing gives you traffic-proportion control (useful for canary deploys, gradual migrations) — you lose this with Multi-Value Answer.
- Multi-Value Answer gives you immediate distribution + built-in health-check failover — essential for persistent protocols under surge.
- Multi-Value Answer requires static IPs (Elastic IPs on NLBs) — ALBs are incompatible.
- For short-lived HTTP traffic, Weighted routing is often fine because connections churn faster than TTL windows concentrate them.
Decision rule¶
If all three of these are true, use Multi-Value Answer: 1. CDN/edge fleet resolving your origin (many parallel resolvers). 2. Persistent-connection protocol (gRPC, WebSocket, SSE). 3. Multiple origin endpoints (NLBs, instances, IPs).
If you need traffic-proportion control for migrations/canaries AND your protocol is short-lived HTTP, Weighted routing is acceptable.
Seen in¶
- sources/2026-07-15-aws-bitdrift-scaled-121-million-grpc-connections-cloudfront — bitdrift's production incident and fix: Weighted → Multi-Value Answer eliminated 80% error rate at 121M concurrent gRPC connections.