Scaling Laws: From Biology to Software Architecture

Mar 26, 2026 · 11 min read · 2298 words · Architecture & Enterprise Enterprise Architecture Scaling Complexity

TL;DR

West’s Scale proposes that organisms, cities, and companies all follow power-law relationships governed by fractal network geometry. Khononov maps that framework onto software architecture, where the “energy” is knowledge flowing across module boundaries. The result: a fractal design principle that applies at every level from bounded contexts to individual aggregates.

Why can we live up to 120 years but not for a thousand or a million? Why do mice live for 2 years, and elephants for up to seventy-five? Despite this difference, why is the number of heartbeats in a life span roughly the same for all mammals (1.5 billion)? Why do almost all companies live for only a relatively few years whereas cities keep growing and manage to circumvent the apparently inevitable fate that befalls even the most powerful and seemingly invulnerable companies? Is there a maximum size for cities?

In his 2017 book Scale, Geoffrey West addresses these questions by proposing universal power-law scaling relationships with size, derived from the geometry of underlying transport and interaction networks and a handful of mathematical invariances.

The originally trained physicist builds on two decades of research. It started with a foundational model for quarter-power allometric scaling in biology (West, Brown & Enquist, 1997), which was then extended to a fractal-geometric theory of the design of organisms (West, Brown & Enquist, 1999). Later, the framework was applied to cities, where socioeconomic output was shown to scale superlinearly with population size while infrastructure scales sublinearly (Bettencourt, Lobo, Helbing, Kühnert & West, 2007; Bettencourt & West, 2010).

The result is an ambitious synthesis: a single mathematical framework that claims to explain why elephants are slow and efficient, why cities get more innovative as they grow, and why companies, unlike cities, are destined to die.

Over time, the work has become immensely popular, especially after the release of the book Scale in 2017. And with good reason, the idea that it would be possible to assemble answers to some of the most complex topics of our lives using simple mathematical intuition.

Why This Matters Beyond Engineering

Scaling laws are not an academic curiosity. They shape the decisions that domain architects, technology leaders, and enterprise strategists face every day.

When an organization doubles its engineering headcount and expects proportional output growth, it is assuming linear scaling. When a data platform team adds a tenth source system and discovers that integration effort has tripled rather than grown by ten percent, they are experiencing superlinear complexity. When a CTO asks why the company’s digital platform feels slower to change than it did three years ago despite more teams and more budget, the answer is often a scaling exponent below one: sublinear returns on investment in an architecture that was never designed to scale.

Cost, performance, sustainability, and organizational agility are all downstream of these dynamics. Understanding which scaling regime your systems operate in, and why, is the difference between architectural decisions that compound and ones that collapse.

The Math

Kleiber’s Law

The starting point of West’s framework is Kleiber’s Law, the empirical observation that metabolic rate scales with body mass as:

$$B = B_0 \cdot M^{3/4}$$

Where $B$ is metabolic rate, $M$ is body mass, and $B_0$ is a normalization constant. The exponent $\beta = 3/4$ is sublinear: doubling an animal’s mass requires only $2^{3/4} \approx 1.68$ times the energy. This systematic economy of scale is the seed from which the entire theory grows.

The WBE Network Derivation

West, Brown & Enquist (1997) derived the $3/4$ exponent from first principles, starting with three assumptions about the vascular network that delivers resources to cells:

Space-filling: the network must reach every cell, so terminal branches fill all available volume.
Terminal unit invariance: the smallest units (capillaries) are identical regardless of organism size.
Energy minimization: evolution has optimized the network to minimize pumping cost.

For a hierarchically branching fractal network with branching ratio $n$, these constraints fix the scaling ratios between successive levels. The space-filling condition forces vessel length to scale as $\gamma = l_{k+1}/l_k = n^{-1/3}$, while area-preserving branching (Murray’s law) gives vessel radius $\beta_r = r_{k+1}/r_k = n^{-1/2}$. Together they produce:

$$B \propto M^{d/(d+1)}$$

Where $d$ is the spatial dimension. For three-dimensional organisms ($d = 3$):

$$\beta = \frac{3}{3+1} = \frac{3}{4}$$

This is the origin of West’s “fourth dimension of life” claim: the fractal network adds an effective extra dimension, yielding $3/4$ instead of the naive surface-area prediction of $2/3$.

The General Scaling Law

All relationships in the framework take the form of a power law:

$$Y = Y_0 \cdot M^{\beta}$$

Where $Y$ is the quantity of interest, $M$ is size (mass or population), $Y_0$ is a normalization constant, and $\beta$ is the scaling exponent. Quarter-power scaling cascades from metabolic rate through biology, cities, and companies:

Biology

Quantity	Scaling	$\beta$	Interpretation
Metabolic rate	$B \propto M^{3/4}$	$3/4$	Larger animals are more energy-efficient
Heart rate	$f \propto M^{-1/4}$	$-1/4$	Larger animals have slower hearts
Lifespan	$T \propto M^{1/4}$	$1/4$	Larger animals live longer
Aorta radius	$r \propto M^{3/8}$	$3/8$	Vessels scale with network geometry
Blood volume	$V_b \propto M^{1}$	$1$	Scales linearly (isometric)
Mass-specific metabolic rate	$B/M \propto M^{-1/4}$	$-1/4$	Each gram burns less in a larger animal

Cities

Quantity	Scaling	$\beta$	Interpretation
Infrastructure (roads, cables)	$Y \propto N^{0.85}$	$\approx 0.85$	Larger cities are more efficient per capita
Socioeconomic output (GDP, patents, crime)	$Y \propto N^{1.15}$	$\approx 1.15$	Larger cities are more productive per capita

Companies

Quantity	Scaling	$\beta$	Interpretation
Revenue, employees	$Y \propto N^{\beta}$	$< 1$	Companies scale like organisms, not cities

The heartbeat invariant follows directly from the biological rows:

$$\text{Lifetime heartbeats} \approx f \cdot T \propto M^{-1/4} \cdot M^{1/4} = M^0 \approx 1.5 \text{ billion}$$

A constant, independent of size. Mice and elephants both get roughly the same number.

For cities, the symmetry is striking: the infrastructure and socioeconomic exponents deviate from 1 by roughly the same amount ($\sim 0.15$), in opposite directions. West argues companies optimize for efficiency rather than innovation, making them captive to their internal distribution networks, just like organisms.

From Physics to Software: Khononov’s Mapping

In his 2022 DDD Europe talk “The Fractal Geometry of Software Design,” Vlad Khononov took West’s framework and asked a deceptively simple question: if organisms, cities, and companies are all energy supply networks governed by the same scaling laws, is software design one too?

His answer: yes. The energy that flows through a software system is knowledge. Modules encapsulate knowledge inside boundaries and let some of it flow across through public interfaces. The type and volume of knowledge shared across boundaries determines how the system scales. Khononov later formalized this model in his 2024 book Balancing Coupling in Software Design (Addison-Wesley), building on the domain-driven foundations laid out in his earlier Learning Domain-Driven Design (O’Reilly, 2021).

Four Levels of Integration Strength

Khononov defines four levels of shared knowledge, ordered from strongest (most knowledge exposed) to weakest (least):

Level	What is shared	Example
Implementation coupling	Internal implementation details	Reflection on private fields
Functional coupling	Business logic and requirements	Two modules implementing the same rules
Model coupling	Domain model	Shared entity definitions across services
Contract coupling	Explicit integration contract	A published language decoupled from internals

As Ruth Malan puts it: system design is about boundaries. Boundaries define how knowledge flows through a system and what kind of knowledge is shared between components.

The Scaling Crisis

Mapping West’s growth dynamics onto software, Khononov identifies four quantities that evolve at different rates as a system grows:

Quantity	Growth dynamic	Implication
Functionality	Linear	Features are added one at a time
Knowledge (modules needed)	Sublinear	Economy of scale: new features reuse existing infrastructure
Complexity (possible interactions)	Superlinear	Interactions between modules grow faster than the system
Cognitive capacity	Constant	Human cognitive load does not scale (~4±1 chunks)

This is Galileo’s growth limit, restated for software. In 1638, Galileo observed that scaling a structure changes its properties at different rates: weight grows as the cube of height, but resistance to fracture only as the square. Beyond a certain size, the structure collapses under its own weight.

In software, complexity grows superlinearly while cognitive capacity stays flat. Eventually the system “crashes under the weight of its own complexity,” as Khononov puts it in the talk, paraphrasing Galileo. We label it a big ball of mud and promise to rewrite it properly next time.

Two Ways to Extend the Limit

Galileo offered two strategies: adapt the form, or use stronger material. Since engineers with superlinearly growing cognitive abilities do not yet exist, we are left with adapting the form. Khononov invokes Goldratt: technology brings benefits if and only if it diminishes a limitation.

The form that works, in biology and in software, is the same one West identified: a fractal-like hierarchical branching network.

The Fractal Principle: Strength XOR Distance

In both the talk and Balancing Coupling in Software Design, Khononov operationalizes the fractal with two variables: integration strength (how much knowledge is shared) and distance (how far apart the modules are in the hierarchy).

Strength	Distance	Result
Low	High	Loose coupling — costly cascading changes are unlikely
High	Low	High cohesion — frequent changes are cheap to coordinate
Low	Low	Local complexity — unrelated things crammed together
High	High	Global complexity — expensive cascading changes are likely

The design rule is: modularity = integration strength XOR distance. You want them opposite. Never both high, never both low.

Self-Similarity Across DDD Levels

The fractal emerges when you apply this rule at every level of abstraction. As you zoom in, distance decreases and integration strength increases, but the balance holds:

Level	Distance	Integration Strength
Between bounded contexts	High	Low (contract coupling)
Inside a bounded context	Medium	Medium (model coupling)
Between aggregates	Lower	Higher (functional coupling)
Inside an aggregate	Minimal	Highest (implementation coupling)

This is the self-similarity principle. What counts as a “contract” at one level is an “implementation detail” at a higher one. What is “global complexity” at one level is “local complexity” one level up. The ratio between strength and distance stays balanced at every scale, exactly as branching ratios in vascular networks stay constant across levels in West’s derivation.

As Rebecca Wirfs-Brock says: the most effective tool for dealing with complexity is abstraction. Encapsulation is the main form of abstraction by which complexity is managed.

The Homework West Left for Software

Khononov closes the talk by noting that West’s framework requires energy supply networks to satisfy three properties beyond fractal branching.

They must be space-filling (reaching every part of the system) This maps to architectural completeness: every business capability must be owned by exactly one module. No orphaned functionality, no “nobody owns this” zones. Formally, this is the exhaustive partitioning property of a bounded context map in DDD — the union of all bounded contexts must cover the entire problem domain, with no gaps.

Invariant terminal units (the smallest components are the same size regardless of system scale) The natural size of a well-designed module is bounded by cognitive load, not by system size. This is formalized in:

Team Topologies’ cognitive load heuristic: a team (and its owned components) should be sized so that the team can fully understand and maintain it. This size is invariant, it’s a property of human cognition (~4±1 chunks), not of system scale.
DDD’s aggregate pattern: an aggregate is a transactional consistency boundary. Its size is determined by business invariants, not by how many other aggregates exist. A well-designed aggregate in a startup’s system is the same size as one in a Fortune 500’s system.

Optimizable (evolution or design can tune the network) The ability to redraw boundaries, split or merge services, change integration patterns. Formally:

ISO 25010 defines modifiability and modularity as quality attributes.
Fitness functions in evolutionary architecture (Ford, Parsons & Kua, 2017) provide automated, measurable criteria for whether the architecture is maintaining its desired properties as it evolves.
Contract coupling (Khononov’s lowest integration strength) is precisely the property that makes optimization possible. If modules are integrated through explicit and transparant contracts rather than shared implementation details, boundaries can be redrawn without systemic breakage.

A big ball of mud fails all three: capabilities bleed across boundaries (not space-filling), modules grow without limit (terminal units are not invariant), and nothing can be changed safely (not optimizable). That’s Khononov’s implicit point: the three requirements are jointly necessary and sufficient to distinguish a fractal architecture from a monolith.

Bibliography

West, G.B., Brown, J.H. & Enquist, B.J. (1997). “A General Model for the Origin of Allometric Scaling Laws in Biology.” Science, 276(5309), 122–126.
West, G.B., Brown, J.H. & Enquist, B.J. (1999). “The Fourth Dimension of Life: Fractal Geometry and Allometric Scaling of Organisms.” Science, 284(5420), 1677–1679.
Bettencourt, L.M.A., Lobo, J., Helbing, D., Kühnert, C. & West, G.B. (2007). “Growth, innovation, scaling, and the pace of life in cities.” Proceedings of the National Academy of Sciences, 104(17), 7301–7306.
Bettencourt, L.M.A. & West, G.B. (2010). “A unified theory of urban living.” Nature, 467, 912–913.
West, G.B. (2017). Scale: The Universal Laws of Growth, Innovation, Sustainability, and the Pace of Life in Companies, Cities, and People. New York: Penguin Press. ISBN 978-1594205583.
Dodds, P.S., Rothman, D.H. & Weitz, J.S. (2001). “Re-examination of the ‘3/4-law’ of metabolism.” Journal of Theoretical Biology, 209(1), 9–27.
Hatton, I.A., McCann, K.S., Fryxell, J.M., Davies, T.J., Smerlak, M., Sinclair, A.R.E. & Loreau, M. (2015). “The predator-prey power law: Biomass scaling across terrestrial and aquatic biomes.” Science, 349(6252), aac6284.
Hatton, I.A., Dobson, A.P., Storch, D., Galbraith, E.D. & Loreau, M. (2019). “Linking scaling laws across eukaryotes.” Proceedings of the National Academy of Sciences, 116(43), 21616–21622.
Khononov, V. (2021). Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy. O’Reilly Media.
Khononov, V. (2024). Balancing Coupling in Software Design: Universal Design Principles for Architecting Modular Software Systems. Addison-Wesley.
Khononov, V. (2022). “The Fractal Geometry of Software Design.” DDD Europe 2022. https://www.youtube.com/watch?v=1ZyR_tgGTp8
Ford, N., Parsons, R. & Kua, P. (2017). Building Evolutionary Architectures: Support Constant Change. O’Reilly Media. ISBN 978-1491986363.