Fault Isolation
The pattern: when one component fails, the failure stays contained. The rest of the system keeps working. Achieved via boundaries — process boundaries, namespace boundaries, account boundaries, network boundaries. Erlang’s “let it crash” philosophy formalizes this at the language level; Kubernetes pods + namespaces + NetworkPolicies do it at the infrastructure level.
The trade-off: isolation cost vs. blast-radius reduction. Tighter isolation (separate VMs, separate cloud accounts) is more expensive and more secure. Looser isolation (shared kernel, shared cluster, shared accounts) is cheaper but one bad workload can take down others. The right answer is workload-dependent: noisy-neighbor sensitivity, regulatory requirements, security threat model.
[Deepen Year 1 Phase 5 with Go errgroup patterns; Year 1 Phase 7 with K8s namespace + Pod Security; Year 2 Phase 13 with multi-tenancy at scale.]
Related patterns
- Backpressure — circuit breakers are fault isolation expressed as a flow-control primitive.
- Privilege separation — same shape, security framing: smallest blast-radius wins.
- Resource virtualization — namespaces + cgroups are the kernel-level isolation primitive.
- Network policy — the network half of the K8s isolation story.
- Zero-trust networking — the larger framing once “the boundary is everywhere.”
First touched in Year 1 Phase 5 and Year 1 Phase 7; revisited in Year 2 Phase 13 when multi-tenancy on basecamp becomes real.