Nodes, Edges, Directions
A Request as a Walk on a Graph
Every component a request touches is a node: client, DNS resolver, CDN edge, reverse proxy, backend replica, database, cache.
Every connection between two nodes is a directed edge: requests flow forward, responses flow back. The forward edge represents an open TCP connection plus the protocol on top.
A single request is a path through this graph. The total work the system does to answer the request equals the sum of work at each node, plus the latency of each edge.
Why care? Once you draw the graph, properties jump out that are invisible in code:
- Hop count: the number of edges in the path. Each hop adds latency (network round trip + node processing). Fewer hops = lower floor on latency.
- In-degree: how many edges point INTO a node. High in-degree means the node receives requests from many sources & must scale or shield itself.
- Out-degree: how many edges point OUT of a node. High out-degree means the node depends on many downstreams & has many ways to fail.
- Cut vertex: a single node whose removal disconnects the graph. A reverse proxy with no peer is a cut vertex; removing it removes all access to its origins.
Where Traffic Concentrates
Fan-In = Concentration
In-degree of a node = number of edges pointing into it. In a request graph, in-degree = number of upstream sources that send requests.
Fan-in pattern: many clients -> one CDN; many CDN edges -> few origin proxies; many proxies -> fewer backend replicas; many backends -> single database.
Concentration matters because the highest in-degree node sees the most aggregate load. The DB at the end of the chain may see queries from every active request in the entire system, even if no single user generates much.
Fan-Out = Dependency
Out-degree of a node = number of edges pointing out of it. High out-degree means many downstream dependencies.
A backend that calls a database, two caches, three external APIs, & a queue has out-degree 7. Its success probability is roughly the product of each downstream's success probability (if all are required for a successful response).
0.999 ^ 7 ≈ 0.993: a backend with 7 downstreams each at 99.9% reliability can only achieve ~99.3% reliability itself, even with no bugs of its own.
Reduce out-degree by: caching downstream results, making non-critical downstreams optional (graceful degradation), parallelizing what can be parallel.
The Asymmetry
Fan-in concentrates load; fan-out multiplies risk. A well-shaped graph minimizes both at the highest-impact nodes.
The database (highest fan-in): cache aggressively to reduce load. Read replicas to spread fan-in across multiple nodes.
The orchestrator service (highest fan-out): circuit breakers per dependency, graceful degradation, bulkheads.
An Inserted Node Buys Flexibility
Indirection = Adding an Intermediate Node
Without a proxy, the graph is: client -> backend. The client must know about the backend's address. Moving the backend requires updating the client (via DNS or configuration). This is a tight binding.
With a proxy, the graph becomes: client -> proxy -> backend. The client knows only about the proxy. Moving the backend requires updating the proxy's upstream configuration, not the client.
The graph operation: insert a node along an existing edge. The new edge client -> proxy is stable; the new edge proxy -> backend is now the team's to manage.
Geometric reading: indirection adds a layer that decouples upstream change from downstream change. Each layer's edges can rewire independently.
Cost of Indirection
Each layer adds:
- One hop of latency (the edge from client to proxy)
- One more cut vertex on the path (the proxy itself)
- One more place where misconfiguration can happen
The benefits (rewire, scale, shield, terminate TLS, distribute load) usually outweigh the costs for any non-trivial system. But there is a limit: every indirection layer adds another hop & another SPOF candidate.
The folklore rule: any problem can be solved by adding a layer of indirection (except the problem of too many layers of indirection).
Read an Architecture as a Graph
Synthesis
You can now read a system architecture as a graph: count hops, identify cut vertices, measure fan-in concentration, compute availability ceilings from fan-out, & evaluate indirection trade-offs.
Apply all four.
A new service has this architecture: clients -> CDN -> reverse proxy (2 replicas) -> backend tier (8 replicas) -> { DB primary, cache cluster (3 nodes), external API }.
Companion Notes
Companion Notes
This geometry-of lesson recasts the Proxies & Origins main lesson as a directed-graph analysis.
The next companion in this course, geometry_of_stateless_horizontal_scaling, takes the replica-math from the main scaling lesson & derives the queueing curve, Little's Law, & the 80% utilization knee geometrically.
Well done.