The architect split the monolith into dozens of small services.
Each service was simple and focused.
The senior developer observed the network calls multiplying exponentially.
“We have eliminated complexity,” said the architect.
“Where did it go?” asked the senior.
Understanding the Koan
This koan confronts one of the most seductive beliefs in modern software architecture: that we can eliminate complexity through decomposition. The architect’s confidence represents our collective faith in the microservices pattern—the idea that by breaking a large system into smaller, focused pieces, we make everything simpler and more manageable.
But the senior developer’s question cuts to the heart of a fundamental truth: complexity in software systems is often conserved rather than eliminated. When we split a monolith into microservices, we trade the complexity of internal coupling for the complexity of distributed systems. What was once a method call becomes a network request. What was once a stack trace becomes a distributed trace across multiple services. What was once a transaction becomes an eventual consistency problem.
The network calls “multiplying exponentially” is not hyperbole—it’s the mathematical reality of distributed systems. If service A needs data from services B and C, and service B needs data from service D, a single user request can cascade into dozens of network calls. Each of those calls brings its own failure modes: timeouts, retries, circuit breakers, load balancers, service discovery. The complexity hasn’t vanished; it has transformed and, in many cases, multiplied.
This koan invites us to be honest about our architectural decisions. Microservices can be valuable when we need independent deployment, team autonomy, or different scaling characteristics for different parts of our system. But if we’re choosing them because we believe they will make our lives simpler, we may be in for a difficult awakening. The question “Where did it go?” should haunt every architectural discussion, reminding us that complexity doesn’t disappear—it only changes form.
The wisdom here isn’t that microservices are wrong, but that we should approach them with clear eyes. Before splitting a system, we should ask ourselves: Are we prepared to manage the complexity we’re about to create? Do we have the monitoring, tracing, and operational maturity to handle a distributed system? Or are we simply moving complexity from a place where we can see it to places where it will be harder to understand?