Document GeoDNS-first client routing decision

diff --git a/README.md b/README.md
index 2db65ac3293089410e8e13bf7dce5ce5d0ab6b93..9055e047baed8d88e3d3a73fb8fa59738ceca1f4 100644 (file)
--- 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.