11. Non-Dualism

The page fires: checkout error rate up. You open the dashboards and every service is green. Auth is serving, the cart is serving, pricing and payments are healthy, the database is inside its latency budget. Nothing on the board is red.

The request is failing anyway, so you open one trace. A single request id, carried through every call, and the dozen spans line up into one waterfall: the gateway to auth to the cart to pricing to a payment call that waited most of a second on a saturated connection pool three services away, then timed out and retried. No service owns the failure. The trace owns it. It was one request the whole time, and the service names are only where you drew lines across it.

Advaita means not two. The sixth chapter of the Chandogya Upanishad is a father teaching his son, and the teaching is a claim about how to know a thing made of many parts. Uddalaka tells Shvetaketu that by knowing one lump of clay you know everything made of clay, because “the modification is merely a verbal distinction, a name; the reality is just clay.” The pot, the jar, the plate are shapes the clay takes, and each name is a word laid over one substance. He says it again of copper and its ornaments, of iron and its tools, and then he names the substance under all of it. In the beginning, this world was Being, sat, “one only, without a second.” Ekam evadvitiyam: one, without a second. It is the word the tradition turns on, and the word this project is named for.

Hold that phrase precisely. The claim is not “one.” It is “without a second.” The many are real, and they are simply not a second thing standing apart from the one.

The dashboards are green one service at a time because that is how you built them, and how you built them is how you are organized. One team owns payments, another owns the cart, and each watches its own service, its own error budget, its own pager. The boundary is doing real work here. It scopes what you deploy and what fails on its own, and it is about as much as one team can hold in its head without holding the others too. Microservices are the one system willing itself into many, and the willing is deliberate. “Would that I were many,” the Chandogya has Being say before it becomes the world, and you say it too, for good reasons: ship without coordinating, contain a failure instead of spreading it, scale the hot path on its own.

The failures worth waking up for do not honor the lines. Latency accrues along the whole path, and a cascade belongs to the whole graph. The correctness of one checkout spans six services and lives in none of them. You drew the boundary so you could reason locally, and the incident shows up non-local, in the space between the services your dashboards watch.

A distributed trace is the clay made visible. Google’s Dapper, described in a 2010 technical report, gave the pattern its shape: attach one id to a request, carry it through every call, record each span against it. What comes back is the waterfall, the request reassembled from the pieces the architecture scattered it into. OpenTelemetry is that same idea, now standard. The trace crosses every service boundary because causation does, and it follows the request from end to end.

The boundaries themselves are what the Chandogya calls the pot: namadheya, a name. Melvin Conway wrote the engineering form of that sentence in 1968. Organizations, he said, “are constrained to produce designs which are copies of the communication structures of these organizations.” The service boundary is a name that arose from speech, from the org chart, the team split, the standup. Three thousand years apart, one claim: the division you see is a name laid over one substance, and the name came from how the people talking were arranged.

You can tell a name from a law by trying to move it. Reorganize the teams and, given the will to refactor behind it, the architecture drifts to match; the tactic has a name of its own, the inverse Conway maneuver, named at ThoughtWorks the year Dapper was published. Reshuffling a room moves no law of physics. It moves service boundaries, because those were made of talk to begin with.

So causation crosses the boundary as freely as if it were not there. The slow payment call blocks a thread in the cart, which fills its pool, which times out the gateway. The timeout did its job; it bounded the wait. Then the gateway retries with no budget on the retries, and that retry, the very thing you added to survive a failure, is what spreads the load. Every hop was a boundary, and the failure crossed all of them. This is why bulkheads and circuit breakers exist. Michael Nygard named them in Release It as things you add, on purpose, so that one service’s failure does not become every service’s failure. You build the isolation. The oneness is what you get for free.

Causation runs the length of the request, service to service, paying latency and risking a dropped call at every crossing, and it never asks the lines you drew for permission. The boundaries are marks on a map. The system under the services is one causal graph, and each service is a region of it you named and shipped on its own.

Where does the oneness bite? Wherever a property belongs to the path and not to any node. Tail latency is the plainest case. Dean and Barroso, in “The Tail at Scale,” lay out the arithmetic. A service that is usually fast but whose ninety-ninth percentile is one second will be slow for one request in a hundred, which sounds survivable, until a single request fans out to a hundred such services and has to wait for the slowest of them. Then sixty-three of every hundred requests are slow, if the slow moments are independent, which they often are not. Each service met its target. The request missed it. The user waits on the whole, and the whole is worse than any piece of it.

The boundary stays real wherever it does operational work. A segfault in payments cannot corrupt the cart’s heap. Payments can be down while search still serves. You deploy one service on Tuesday and leave the rest alone. Those separations are worth keeping, and non-dualism does not ask you to give them up. A pot holds water, and it was only ever clay in a shape. Your payment service bills real customers, and it is still a region of the one graph. That is what “without a second” means. The boundary does real work; it just does not reach all the way down.

That denial has a floor, and honesty lives at the floor. The system is one causal graph because you built it to serve one request, so the oneness is engineered, and it is scoped to that purpose. Two services that share no request and no datum are simply two. The Upanishad makes the unscoped claim and follows it all the way out, one without a second, being itself. A distributed system makes the bounded version, one within the reach of a shared request. The cosmos is not a trace. Keep the mapping inside the fence where it holds, and it stays true.

Go back to the trace from the start. It gave you the easy oneness. The dozen spans were one request, and following the id you found the pool three services away and the retry that spread the load. That is the ordinary gift of tracing: the many resolve into the one, and the one can be read.

There is a harder oneness the trace cannot show you. Some failures sit in no span. A system runs fine under load, takes a small shock, a brief dependency blip, and instead of recovering it stays down. The recovery work, the retries and the cold caches refilling, now makes more load than the traffic that started it, and the overload feeds itself long after the trigger is gone. This is a metastable failure, named in a 2021 workshop paper by Bronson and colleagues. Every part looks busy: the retries fire, the pools stay full, throughput holds high. What has collapsed is the useful work, the goodput, and that number lives in no single place. No one service is the root cause, and no single trace contains it. The failure is the loop the whole graph fell into, and no service owns it.

The Chandogya presses one phrase on Shvetaketu nine times over, tat tvam asi, that art thou, until he cannot stand outside the thing he is studying. The metastable failure is that sentence in production. You do not get to stand outside the system and watch it fail. The failure with no owner is on your pager, because a system with no seam in it is one, and you are on call for the whole.

The dashboards will be green again tomorrow, one service at a time, because that is how you drew them. The request that failed never read the org chart. It ran through every service as one motion and failed as one thing, and the trace only showed you what was true before you split the work into services: it was one all along. You draw the boundaries to ship. The trace is where the one request stays visible after you have cut it into a dozen.