📖 Business
Fowler's First Law
Fowler's First Law of Distributed Objects states: "Don't distribute your objects." This deceptively simple principle argues that distributing an application across multiple processes or machines should be a last resort driven by concrete requirements (scalability, team autonomy, regulatory isolation), not a default architectural choice. Distribution introduces latency, partial failure modes, data consistency challenges, and operational complexity that dwarf the problems it supposedly solves. Fowler observed that many enterprise teams distributed their systems prematurely — often because distributed architectures were fashionable — and spent the majority of their development effort managing the accidental complexity of network boundaries rather than solving business problems.
2
Minutes
2
Concepts
+45
XP
1
How It Works
- The cost of distribution — Every call across a process or network boundary is orders of magnitude slower than an in-process method call. A local method call takes nanoseconds; a remote call takes milliseconds at best. This 1,000x-1,000,000x performance penalty means distributed interfaces must be designed fundamentally differently from local interfaces — coarse-grained, batch-oriented, tolerant of failure.
- Remote interfaces vs. local interfaces — Local interfaces can be fine-grained:
customer.GetName(),customer.GetAddress(),customer.GetOrders(). Remote interfaces must be coarse-grained to minimize round trips:customer.GetCustomerWithOrdersSummary(). This distortion ripples through the entire design, producing DTOs (Data Transfer Objects), facade layers, and serialization logic that exist solely because of the distribution boundary.
- The eight fallacies of distributed computing — Fowler reinforces Deutsch's fallacies: the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology doesn't change, there is one administrator, transport cost is zero, the network is homogeneous. Every distributed system must eventually reckon with all eight.
- When distribution is justified — Fowler isn't anti-distribution; he's anti-premature distribution. Valid reasons include:
- Scalability: a single machine genuinely can't handle the load
- Team autonomy: independent teams need to deploy independently
- Security isolation: regulatory requirements mandate separate processes
- Technology heterogeneity: different components require different runtimes
The key word is "forced" — distribute when you must, not when you might.
- The monolith-first approach — Start with a well-structured monolith (properly layered, modular, with clean internal boundaries). Extract services only when a specific, measurable need arises. A well-modularized monolith can be decomposed later; a prematurely distributed system is extremely difficult to re-merge.