We've all been there. You design an architecture, it looks clean on the whiteboard, everyone agrees it's solid. Then a provider goes down, and the architecture that looked great on paper crumbles in ways nobody predicted.

Most architecture approaches treat these surprises as edge cases to be handled later. Residuality Theory starts from the assumption that they're inevitable, and makes them the foundation of the design process.

What is Residuality Theory?

Residuality Theory is a framework for software architecture created by Barry O'Reilly. He published it in his book Residues: Time, Change, and Uncertainty in Software Architecture, and it is based heavily on complexity science.

The terms used are minimal:

  • Stressors: things that can go wrong or change. Technical failures, user behaviour, regulatory changes, vendor risks.
  • Residues: what's left of your system after a stressor hits. A residue can be desirable ("the system gracefully degrades") or undesirable ("the system is down and the user is stuck").

The key insight: randomness is the point

The theory's assumption is that in any sufficiently complex system, you cannot know which stressors will hit, in what order, or at what scale. And those properties aren't static either: a stressor hitting a system that already absorbed another stressor lands differently than it would on a fresh system.

So instead of trying to predict the future, you randomly simulate stress.

You start with a naive architecture (either your current architecture or the simplest thing that could work in a greenfield environment). Then you throw stressors at it in random order. For each one, you ask: "What's left? Is that residue desirable or not?" If it's not, you adapt the architecture to make it survive better.

After this exercise, you check which architectural adaptations converge from this session. You design a new architecture that accounts for the most common adaptations. After that, you can take a new random sample of stressors and apply it to your new architecture, as if this were your naive architecture. If you end up with more desirable residues than before, you've come to a more resilient architecture. If not, you can do a second iteration.

The counterintuitive bit is that this randomness is what gives the architecture its strength. You're not designing for a specific sequence of failures or working through a ranked risk register from top to bottom. You're designing for any sequence. The architecture that emerges from random stress is more resilient than one designed against a checklist of known risks, because it doesn't depend on your ability to predict the future correctly.

With enough random stressors, something interesting happens: the design converges. New stressors stop revealing new weaknesses. They're already covered by residues you designed for earlier, unrelated stressors. That convergence is your signal that the architecture is stabilising. The result is greater than the sum of its parts: a system whose overall ability to respond to unknown stress matters more than any individual component.

Why this is worth knowing

This is not the one true way to do architecture, but it embraces uncertainty instead of pretending we can spec it away. Most approaches assume you can gather enough requirements upfront to make good design decisions. Residuality Theory assumes you can't, and gives you a method that works anyway. And even if you never adopt the full methodology, "let's brainstorm stressors and see what survives" is a useful exercise for any architecture discussion. It gives you another way of thinking about architecture.

Where to go from here

If this piqued your interest, you can read Barry O'Reilly's book Residues.