If you’ve studied for an AWS certification, you’ve memorized the difference between weighted, latency-based, and failover routing policies in Route 53. You’ve also probably forgotten why any of it matters the moment you passed the exam. Bitdrift’s recent work scaling to 121 million concurrent gRPC connections during live sporting events is a good reminder that these aren’t trivia questions. They’re load-bearing architectural decisions, and getting them wrong doesn’t cost you an exam point. It costs you an outage in front of millions of viewers.
The Exam Question That Wasn’t Theoretical#
Every AWS study guide covers the same routing policies. Weighted routing splits traffic across resources by percentage. Latency-based routing sends users to whichever endpoint responds fastest. Failover routing keeps a backup resource on standby and reroutes traffic when the primary fails a health check.
On a study guide, these are four multiple-choice answers with one correct pick. In production, at the scale bitdrift was operating, they’re the difference between a distributed system and a single point of failure wearing a distributed system’s clothing.
A gRPC connection isn’t like an HTTP request. It’s long-lived. Clients open a connection and keep it open, often for the duration of an event. When you’re talking about 121 million of those connections concurrently, during a live sporting event where everyone connects around the same moment, your DNS routing decisions determine whether that load spreads across your infrastructure or piles up on whichever origin happened to answer first.
Where Misapplied Routing Becomes a Single Point of Failure#
Consider this scenario: You set up a simple routing policy because it’s the default and you never revisited it. Every new client resolves the same domain name, gets the same answer, and connects to the same origin.
That’s fine at low volume. It’s catastrophic at high volume. A single origin endpoint absorbing a meaningful fraction of 121 million long-lived connections doesn’t degrade gracefully. It falls over, and when it falls over, it takes every client attached to it down at once, because gRPC connections don’t quietly retry the way a stateless HTTP request might.
This is exactly the failure mode that weighted routing and latency-based routing exist to prevent. Weighted routing spreads new connections across multiple origins by design, so no single resource absorbs a disproportionate share. Latency-based routing does something subtler: it routes based on which origin can actually serve the client fastest, which in effect load-balances by geography and network conditions rather than by a fixed ratio you set once and forgot about.
Failover routing matters here too, but for a different reason. With connections this long-lived, you can’t treat failure detection as an afterthought. You need Route 53 health checks actively monitoring origin health so that a failing endpoint gets pulled out of rotation before it drags down every client still holding an open connection to it.
CloudFront Doesn’t Save You From a Bad DNS Strategy#
A common assumption is that putting CloudFront in front of your architecture solves the distribution problem automatically. It doesn’t. CloudFront’s edge network is excellent at caching and terminating connections close to the user, but it’s not a substitute for correct origin selection. If your DNS routing funnels traffic toward a narrow set of origins behind CloudFront, you’ve just moved your single point of failure one layer deeper. It’s still there. It’s just harder to see.
CloudFront delivers resilience only when it sits on top of a DNS strategy that’s actually doing its job. That means your routing policies need to reflect the real distribution of your infrastructure, not just the distribution you configured on day one and never touched again.
The Takeaway#
Ask yourself which policy your production traffic is actually using right now, and whether that choice still matches your current scale and topology.
At 121 million concurrent connections, there’s no room for a routing decision that was correct for a demo but never revisited for production. The bitdrift numbers are a stress test you may never personally run. But the fundamentals it exposes, weighted distribution, latency awareness, and honest failover, apply at any scale where you can’t afford one origin to become the whole system’s fate.
Recommended Reading#
- Networking All-in-One For Dummies by Doug Lowe
- CompTIA Network+ Study Guide: Exam N10-009 by Todd Lammle
- AWS Certified Solutions Architect Study Guide: Associate SAA-C03 Exam, 4th Edition by Ben Piper & David Clinton
Featured image by Max Harlynking on Unsplash