Der Engpassknoten wird identifiziert, bevor der Verkehr eintrifft
Betweenness-Zentralität
Für jedes Knotenpaar in einem Graphen gibt es einen kürzesten Pfad zwischen ihnen. Die Betweenness-Zentralität eines Knotens N = der Anteil aller kürzesten Pfade, die durch N verlaufen.
Ein Knoten mit hoher Betweenness liegt auf dem Pfad zwischen vielen anderen Paaren. Wenn er langsamer wird, werden viele Datenströme langsamer. Wenn er ausfällt, brechen viele Datenströme ab.
Architektonische Einordnung: Knoten mit hoher Betweenness sind diejenigen, auf die jede Architekturprüfung besonderen Wert legen sollte. Sie sind Engpässe, SPOFs & kapazitätskritische Komponenten in einem. Sie neigen dazu, zu sein:
- Der DNS-Provider (zwischen jedem Client & jedem Dienst)
- Der Ingress-Proxy (zwischen jedem Client & jedem Backend)
- Die Datenbank-Primärinstanz (zwischen jedem Backend & jedem Lesevorgang)
- Der Authentifizierungsdienst (zwischen jedem Benutzer & jeder autorisierten Aktion)
Erkennung ohne Messung: Die Graphentopologie allein identifiziert Knoten mit hoher Betweenness. Man benötigt keine Traffic-Daten; man benötigt das Architekturdiagramm. Ein Knoten, der zwischen vielen Paaren anderer Knoten liegt, ist strukturell kritisch.
Operative Konsequenz: Knoten mit hoher Betweenness verdienen eine überproportionale Investition in (1) Kapazitätsreserve, (2) Redundanz, (3) Observability & (4) Incident-Response-Playbooks.
Der kleinste Schnitt trennt den kleinsten Teil
Min-Cut-Theorem in einfachen Worten
Der Min-Cut zwischen zwei Knoten in einem Graphen = die kleinste Anzahl an Kanten (oder Knoten), die entfernt werden müssen, um sie zu trennen.
Operationelle Interpretation: Der Min-Cut begrenzt den Worst-Case-Blast-Radius. Wenn der Min-Cut zwischen „Clients“ und „Datenbank“ 1 Kante beträgt (ein einzelner Proxy), führt der Verlust dieser Kante dazu, dass alle Clients von der Datenbank getrennt werden. Wenn der Min-Cut 5 beträgt, müssen 5 Komponenten gleichzeitig ausfallen, um eine vollständige Trennung herbeizuführen; Pech, aber begrenzt.
Design für den Blast-Radius: Erhöhe den Min-Cut an jeder wichtigen Grenze. Mehrere Proxys; mehrere Cache-Knoten; mehrere Netzwerkpfade zwischen Rechenzentren. Jede Ergänzung erhöht den Min-Cut um 1.
Das Bulkhead-Muster in Graphen-Begriffen: Teile Ressourcen in separate Teilgraphen auf, die keinen gemeinsamen Min-Cut miteinander teilen. Ein Ausfall innerhalb eines Teilgraphen kann sich nicht auf die anderen ausbreiten, da die Kanten nicht existieren.
Durchmesser bestimmt die Ausbreitungsdistanz von Fehlern
Graphendurchmesser = der längste kürzeste Pfad zwischen zwei beliebigen Knoten.
Fehlerausbreitung: Wenn ein Knoten ausfällt und Retries zurückfließen, betreffen sie Upstream-Knoten bis zum Durchmesser-Entfernung. Ein System mit Durchmesser 3 (Client -> Proxy -> Backend -> DB) bedeutet, dass ein DB-Ausfall 3 Upstream-Ebenen in einem Retry-Storm betrifft.
Implikation: Kürzerer Durchmesser = schnellere Fehlerisolierung, aber auch höhere Knotenkonzentration. Jedes Design hat seine eigenen Kompromisse.
Min-Cut für eine reale Architektur berechnen
Eine Architektur: 1 DNS, 1 CDN, 3 Reverse Proxys, 12 Backend-Replikate, 1 DB-Primärknoten.
Audit von Fehlermodi über Graphenmetriken
Synthese
Sie können nun Knoten mit hoher Betweenness identifizieren, den Min-Cut an jeder Grenze berechnen und die Ausbreitungsdistanz von Fehlern über den Durchmesser schätzen.
Wenden Sie alle drei Methoden an.
Ein System: 50 Kundendatenendpunkte -> 1 DNS -> 2 CDN-POP-Standorte -> 4 Reverse Proxys -> 16 Backend-Replikate -> { DB-Cluster (1 Primär + 2 Standbys), Redis-Cluster (5 Knoten), 3 externe APIs }.
Begleitnotizen
Begleitnotizen
Diese Geometrie-Lektion formuliert die Hauptlektion Fehlerszenarien & Auswirkungsradius neu über Graphenmetriken (Betweenness, Min-Cut, Durchmesser).
Die letzte Begleitnotiz, geometry_of_observability_and_capacity, behandelt Voronoi-Zellen für CDN-PoP-Einzugsgebiete, den Lichtgeschwindigkeitsuntergrenze des Latenzdreiecks & die erneut betrachtete Warteschlangenkurve auf der Proxystufe.
Gut gemacht.