What is the load path?

In structural engineering the load path is the route a force takes through a building to the ground. Cut it anywhere and the structure fails, no matter how strong the other members are. Software has the same property and less habit of drawing it.

What do we mean, precisely?

Take one user action that pays your bills: checkout, search, claim submission. The load path is every component that action touches, in order, including the ones nobody mentions: the DNS resolver, the connection pool, the auth middleware that calls a second service, the audit write that happens synchronously because it always has. Not the architecture diagram. The actual route, as production runs it today.

We open every review by tracing one, with the team in the room, and we have never once finished without a surprise. The record so far is a checkout path that touched nineteen components; the diagram showed seven. The other twelve had accreted, one reasonable decision at a time, the way the arrows nobody drew always do.

Why trace it before measuring anything?

Because capacity, latency and availability are all properties of the path, not of the parts. A system of ten components each at 99.9% availability offers roughly 99% at the path level: an hour higher error budget spent per component means the path's promise is the product, not the minimum. The same arithmetic governs latency, where the slowest hop, not the average, shapes what users feel; the canonical treatment is Dean and Barroso's The Tail at Scale, which we assign as pre-reading more than any other paper.

The path also answers the question teams usually bring us, "what would have to be true for this to survive doubling?", better than any single component's benchmark. Doubling breaks paths at their narrowest point, and the narrowest point is frequently something unglamorous: a connection pool sized in 2021, a synchronous call to a service that was never meant to be load-bearing.

What does tracing cost, and what does it earn?

An afternoon, in practice. Distributed tracing makes it nearly free where it's deployed; where it isn't, one engineer with the logs and a whiteboard gets ninety percent of the value. What it earns is a shared, falsifiable picture: the prerequisite for every capacity model, every incident review, every argument about what to fix first.

Our rule, offered as-is: no scaling conversation until the load path of the top three revenue actions is drawn, dated, and disagreed with by at least one person in the room. The disagreement is the finding. Buildings get load paths by calculation before construction. Systems grow theirs by accretion afterward, which is why someone has to go look.