Knooppunten, Kanten, Richtingen
Een Verzoek Als Een Wandel Door Een Graf
Elk component dat een verzoek raakt is een knooppunt: client, DNS-resolver, CDN-edge, reverse proxy, backend-replica, database, cache.
Elke verbinding tussen twee knooppunten is een gerichte kant: verzoeken stromen vooruit, antwoorden stromen terug. De voorwaartse kant vertegenwoordigt een open TCP-verbinding plus het protocol daarbovenop.
Een enkel verzoek is een pad door deze graf. Het totale werk dat het systeem verricht om het verzoek te beantwoorden, is gelijk aan de som van het werk op elk knooppunt, plus de latentie van elke kant.
Waarom is dit belangrijk? Zodra je de grafiek tekent, worden eigenschappen zichtbaar die in de code onzichtbaar zijn:
- Hop-aantal: het aantal randen in het pad. Elke hop voegt latentie toe (netwerkronde + verwerking op de node). Minder hops = lagere ondergrens voor latentie.
- Ingraad: het aantal randen dat naar een node wijst. Een hoge ingraad betekent dat de node verzoeken ontvangt van veel bronnen en zich moet schalen of beschermen.
- Uitgraad: het aantal randen dat van een node afwijst. Een hoge uitgraad betekent dat de node afhankelijk is van veel downstream-systemen en op veel manieren kan falen.
- Scheidingsteken (Cut vertex): een enkele node waarvan de verwijdering de grafiek in tweeën deelt. Een reverse proxy zonder peer is een scheidingsteken; het verwijderen ervan vermindert alle toegang tot de oorsprongsystemen.
Waar verkeer zich concentreert
Fan-In = Concentratie
De in-grad van een knoop = het aantal randen dat naar binnen wijst. In een verzoekengraf is de in-grad = het aantal upstream-bronnen die verzoeken sturen.
Fan-in-patroon: veel clients -> één CDN; veel CDN-edges -> weinig origin-proxies; veel proxies -> minder backend-replica's; veel backends -> één database.
Concentratie is belangrijk, omdat het knooppunt met de hoogste in-degree de grootste totale belasting ziet. De DB aan het einde van de keten kan queries van elke actieve request in het hele systeem zien, zelfs als geen enkele gebruiker veel genereert.
Fan-Out = Afhankelijkheid
Out-degree van een knooppunt = aantal randen dat uit het knooppunt wijst. Een hoge out-degree betekent veel downstream-afhankelijkheden.
Een backend die een database, twee caches, drie externe API's en een wachtrij aanroept, heeft een out-degree van 7. De kans op succes is ongeveer het product van de succeskans van elke downstream (als alle vereist zijn voor een succesvolle respons).
0,999 ^ 7 ≈ 0,993: een backend met 7 downstreams, elk met 99,9% betrouwbaarheid, kan zelf slechts ~99,3% betrouwbaarheid bereiken, zelfs zonder eigen bugs.
Verlaag de out-degree door: downstream-resultaten te cachen, niet-kritieke downstreams optioneel te maken (graceful degradation), en wat parallel kan, parallel uit te voeren.
De Asymmetrie
Fan-in concentreert de belasting; fan-out vermenigvuldigt het risico. Een goed vormgegeven grafiek minimaliseert beide op de knooppunten met de grootste impact.
De database (hoogste fan-in): cache agressief om de belasting te verminderen. Gebruik leesreplica's om de fan-in over meerdere knooppunten te spreiden.
De orchestrator-service (hoogste fan-out): circuit breakers per afhankelijkheid, elegante degradatie, bulkheads.
Een ingevoegde knoop koopt flexibiliteit
Indirectie = Een tussenvoegde knoop toevoegen
Zonder proxy is de graaf: client -> backend. De client moet de adresgegevens van de backend kennen. Als de backend verplaatst wordt, moet de client bijgewerkt worden (via DNS of configuratie). Dit is een strakke koppeling.
Met een proxy wordt de graaf: client -> proxy -> backend. De client kent alleen de proxy. Als de backend verplaatst wordt, moet de upstream-configuratie van de proxy bijgewerkt worden, niet de client.
De graafoperatie: voeg een knoop in langs een bestaande rand. De nieuwe rand client -> proxy is stabiel; de nieuwe rand proxy -> backend is nu aan het team om te beheren.
Geometrische interpretatie: indirectie voegt een laag toe die upstream-veranderingen ontkoppelt van downstream-veranderingen. De randen van elke laag kunnen onafhankelijk van elkaar opnieuw worden aangesloten.
Kosten van indirectie
Elke laag voegt toe:
- Eén extra vertraging (de verbinding van client naar proxy)
- Nog een knikpunt op het pad (de proxy zelf)
- Nog een plek waar misconfiguratie kan optreden
De voordelen (herkabelen, schalen, beschermen, TLS afhandelen, belasting verdelen) wegen in de meeste niet-triviale systemen zwaarder dan de kosten. Maar er is een limiet: elke laag indirectie voegt een extra hop en een extra SPOF-kandidaat toe.
De volksverklaring: elk probleem kan worden opgelost door een laag indirectie toe te voegen (behalve het probleem van te veel lagen indirectie).
Een architectuur lezen als een graaf
Synthese
Je kunt nu een systeemarchitectuur lezen als een graf: tel sprongen, identificeer knikpunten (cut vertices), meet de concentratie van fan-in, bereken beschikbare plafonds uit fan-out, & evalueer de afwegingen bij indirecte verwijzingen.
Pas alle vier toe.
Een nieuwe service heeft deze architectuur: clients -> CDN -> reverse proxy (2 replicas) -> backend tier (8 replicas) -> { DB primary, cache cluster (3 nodes), external API }.
Notities bij de les
Notities bij de les
Deze les over geometrie presenteert de hoofdlees Proxies & Origins opnieuw als een analyse van een gerichte grafiek.
De volgende bijles in deze cursus, geometry_of_stateless_horizontal_scaling, neemt de replica-berekeningen uit de hoofdlees over schaling en leidt de wachtrijcurve, de Wet van Little en de knie bij 80% benutting geometrisch af.
Goed gedaan.