Hermes Wiki
Synthesis/weighted-routing-as-shared-traffic-shifting-primitive

Synthesis: Weighted Routing Is the Same Traffic-Shifting Primitive Across a Fundamentals Note, an AWS Case Study, and the Exam Scope Guide — Never Cross-Linked

The connection

Three vault files — one new this window, two from the prior window but still unlinked to it — all describe the identical underlying mechanism (shift a fraction of traffic to a different backend, by key or by weight, without a client-visible cutover) but were written independently and never cross-reference each other:

  • Load Balancing Algorithms (new this window) lays out the abstract framework: load-optimizing algorithms (round robin, least connections) vs. affinity-preserving consistent hashing, and names Route 53 nowhere despite DNS-level weighted routing being a real-world instance of exactly the "shift traffic without reshuffling everything" problem the note spends most of its space on.
  • AWS: Hybrid Multi-Tenant Architecture (unchanged, 08-03) uses Route 53 weighted routing as its specific mechanism for migrating a tenant's traffic between ECS clusters "without any client-visible cutover" — a live, concrete case of the exact tradeoff load-balancing-algorithms.md describes in the abstract.
  • AWS_Scope.md (unresolved) (changed this window) documents Route 53's routing policies (Simple, Weighted, Latency-based, Failover, Geoproximity) and separately documents ELB/ALB, Global Accelerator, and Gateway Load Balancer — the exam-scope vocabulary for the same family of mechanisms — with no pointer to either of the other two notes.

Why this matters

This is a case of the same design primitive existing at three levels of abstraction in the vault — general concept, real-world application, vendor-specific service catalog — that grew independently because they were written in different folders on different days for different purposes (Fundamentals for timeless concepts, CaseStudies for real engineering writeups, CertExams for exam prep). None of the three treats DNS-level weighted routing and Layer-4/7 load-balancer algorithm selection as the same underlying decision, even though "pick a mechanism that shifts a fraction of traffic to a different backend, by key or by weight, with minimal blast radius" is one design question with the same tradeoffs (even load vs. affinity/gradual-migration) regardless of whether the mechanism sits at the DNS layer (Route 53) or the connection layer (ALB/NLB algorithm choice).

What this suggests

  • load-balancing-algorithms.md's "Related" section is a natural place to add a pointer to the AWS hybrid multi-tenant case study as a worked example of weighted-routing-as-migration-tool — it currently only links to database-sharding-strategies and caching-strategies, both about consistent hashing, and misses its own case-study instance.
  • AWS_Scope.md's Route 53 and ELB sections are good candidates for the same inline cross-reference pattern already used elsewhere in that file (e.g. its Elasticache section explicitly points to Architecture/Fundamentals/caching-strategies) — right now Route 53/ELB/Global Accelerator sit as pure vendor trivia with no link back to the vendor-neutral tradeoff framework that would explain why AWS offers this many mechanisms for what is structurally one decision.
  • This is also a case-in-point for the AWS_Scope.md pattern itself: the file already selectively cross-links to Fundamentals notes where a mapping is obvious (caching, disaster recovery) but the mapping is incomplete — worth a pass checking which other AWS_Scope sections (e.g. Auto Scaling policies vs. autoscaling-strategies.md) have the same gap.
Hermes Wiki