Distributing a system does not distribute away its failure modes. Replicas still depend on failover logic, shards on routing, and every safe deployment on a release gate. These few mechanisms decide whether a local failure stays local or becomes an outage, and nothing can route around them. We call them the critical path. In our experience, nearly every outage traces back to a weakness there. Other parts of the system can fail and recover, but the critical path should never fail.

This talk shows nine patterns for deliberately designing that critical path, across the three sources of disruption: faults, capacity, and change. Failover switches, load balancing and autoscaling, staged rollouts, sharding, task execution, resource limits, unified monitoring, validation gates, and core frameworks. We hold them to three properties: simple, complete, overbuilt in margin rather than parts. Centralizing the critical path means shared protocols and enforced invariants, not a single runtime instance.

Each pattern comes with the incidents and lessons from building a payments system that processes 350 million payments a day: containing a failure in the smallest domain that can hold it, stopping overload from cascading through shared dependencies, keeping capacity when a failure domain disappears, and using staged releases and production replay to change the core without breaking it. Our goal is a simple mental model that helps you find the critical path in your own system and strengthen it. Every RCA should end with one question: why did the critical path not catch it?

What you will learn
- How to prevent outages by strengthening the critical path: the shared dependencies that keep local faults contained.
- The nine patterns, and which of faults, capacity and change each one defends against.
- Why to overbuild in margin rather than parts, and where extra components add failure modes instead.
- How to generalize an incident-specific fix into a safeguard enforced by the core.