Is distributed system topology the last major architectural concern that's still mostly implicit?
I've been thinking about this while building a prototype over the last few months, and I'm curious whether others have run into the same problem.
We made source code explicit.
We extracted configuration from code.
We got infrastructure-as-code.
APIs became first-class artifacts.
But topology—the graph of which components communicate, how they communicate, retry behavior, event subscriptions, transport choices, architectural boundaries—is still mostly encoded throughout implementation.
As a result, questions like:
- What actually depends on this component?
- What breaks if these two services merge?
- Which architectural boundaries are enforced versus just documented?
- What retry policies actually exist in production?
often require reading code, configuration, deployment manifests and documentation together.
My hypothesis is that topology itself should become a first-class architectural artifact, with tooling that can validate and reason about it before deployment, much like infrastructure-as-code changed how we think about deployment.
I built an open-source prototype to explore that idea, but before discussing the implementation I'm much more interested in whether the premise resonates.
Does this match pain you've experienced, or is topology being implicit simply the right trade-off?
I'd especially appreciate perspectives from architects, staff/principal engineers, and platform teams working on larger systems.
If anyone wants to see the prototype for context: