From: Andrew Gundersen Date: Fri, 17 Jul 2026 19:25:04 +0000 (+0000) Subject: Document GeoDNS-first client routing decision X-Git-Url: https://andrewgundersen.net/repos?a=commitdiff_plain;h=4d6d775c1a4ac36a0b7ccdcd9adb97585acacf79;p=server-iac Document GeoDNS-first client routing decision --- diff --git a/README.md b/README.md index 2db65ac..9055e04 100644 --- a/README.md +++ b/README.md @@ -65,3 +65,27 @@ breakdown of what that would actually require: None of that is implemented yet. This repo is step one: capture the single node's setup so it's reproducible, before deciding whether multi-node is actually worth the added complexity. + +### Client routing decision + +For directing clients to the nearest node once there's more than one, +decided on **GeoDNS first, anycast later if needed**: + +- **GeoDNS** (e.g. Cloudflare/Route53 geo-routing policies): near-zero + extra infrastructure — DNS just returns a different node's IP depending + on the resolver's location. Failover is bounded by TTL (clients keep + using a cached, possibly-dead IP until the record expires), not instant. + A low TTL (~60s, most providers' practical floor) shrinks that window but + doesn't eliminate it - DNS-based routing is fundamentally "wait until the + client asks again," no matter how low the TTL goes. +- **Anycast**: the same IP announced from every node via BGP; the network + itself routes each client to the topologically nearest one, with + near-instant failover since it's not cache-bound at all. The real + answer if "instant" (not just "fast") failover ever actually matters, but + it's a different tier of operational complexity - normally means running + your own ASN/BGP peering, or paying a provider (e.g. Cloudflare Spectrum) + to do it for you. + +Chose GeoDNS for now because it's proportionate to actual scale (one user, +two mailboxes) - revisit anycast only if a real need for sub-TTL failover +shows up, not preemptively.