Core Idea
“The topology never changes” is the fifth of the Fallacies of Distributed Computing—the false assumption that network topology remains static once deployed. In reality, network topology changes constantly through server additions, removals, relocations, failures, load balancer changes, firewall updates, DNS modifications, cloud auto-scaling, container orchestration, and infrastructure evolution, requiring distributed systems to handle dynamic topology without manual reconfiguration.
What Is the “Topology Never Changes” Fallacy?
The fallacy assumes that once a distributed system is deployed, the physical and logical arrangement of servers, networks, and services stays constant. Modern infrastructure is inherently dynamic.
In monolithic applications, topology is trivial — the application runs at a fixed address and only moves during rare, scheduled maintenance. In distributed systems, services must discover and communicate with multiple other services; any change in where those services live requires updating connections, routes, and configurations.
Topology changes occur constantly across several dimensions:
- Physical — servers added for load, removed for maintenance, relocated for disaster recovery
- Logical — services assigned new IPs, moved behind different load balancers, deployed to new ports
- Cloud-native — auto-scaling adds and removes instances; Kubernetes continuously reschedules containers; serverless creates and destroys instances per invocation
- Failure-driven — network switches fail, DNS entries redirect traffic, services crash and restart at different addresses
- Deployment-driven — rolling updates, blue-green deployments, and canary releases all shift traffic across different addresses simultaneously
Services hardcoded to specific IP addresses break when servers move or fail, requiring manual configuration updates during incidents when speed is critical.
Addressing this fallacy requires dynamic discovery and configuration:
- Service discovery (Consul, Eureka, Kubernetes DNS) — locate dependencies by name, not hardcoded address
- Load balancers — abstract individual server addresses behind a stable endpoint
- Health checks — remove failed instances from routing without manual intervention
- Service meshes (Istio, Linkerd) — handle topology changes automatically through control-plane coordination
Why This Matters
A monolith might have minimal external topology — a database and cache. A microservices system with 50 services may have hundreds of inter-service connections, each dependent on correct topology information. When topology changes affect multiple services simultaneously, cascading failures occur as services lose connectivity to dependencies.
For cloud-native systems with frequent deployments and auto-scaling, static topology assumptions guarantee operational failure. Architectures built for dynamic topology enable zero-downtime deployments, elastic scaling, and resilient failure handling — capabilities that distributed architectures need to deliver on their promises.
Related Concepts
- Fallacies-of-Distributed-Computing — The complete set of eight fallacies this belongs to
- Fallacy-The-Network-Is-Reliable — Related fallacy about network failure assumptions
- Monolithic-vs-Distributed-Architectures — The architectural decision this fallacy impacts
- Operational-Characteristics — Deployability and scalability require handling topology changes
- Microservices-Architecture-Style — Style requiring dynamic service discovery
- Trade-Offs-and-Least-Worst-Architecture — Dynamic topology handling exemplifies architectural trade-offs
Sources
-
Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Chapter 9: Foundations
- Discusses the Fallacies of Distributed Computing and their architectural implications
- Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
-
Deutsch, Peter (1994-1997). “The Eight Fallacies of Distributed Computing.” Originally articulated at Sun Microsystems.
- Fifth fallacy in the original list
- Identified through observing distributed systems failing when network topology changed
- Widely referenced in distributed systems literature
Note
This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.