[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-single-point-of-failure::en":3,"gloss-cluster-single-point-of-failure::en":23,"gloss-next-single-point-of-failure::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"single-point-of-failure","cloud","Single Point of Failure","A single point of failure is any component whose loss stops the whole system, no matter how many other parts are duplicated. The phrase is old and still useful because the thing it names is almost never where the architecture diagram suggests. Teams duplicate the obvious pieces early — two servers, two zones, a replica of the database — and then accumulate a second class of dependency that was never designed to be redundant: the one machine that runs the nightly job, the certificate that one person renews, the account whose credentials every service happens to share, the queue that every path goes through, the small internal service written years ago that nothing can start without. Redundancy also fails in a way worth naming, because two copies of something are only independent if they cannot fail for the same reason. Two instances of the same software with the same defect will meet the same input on the same day. Two zones fed by the same configuration will receive the same bad change within a minute of each other. Two providers that both resolve names through the same upstream are one provider for the purpose of that upstream. The useful exercise is not to draw the diagram but to interrogate it: pick each box and ask what happens to a user request if this disappears right now, and then ask the same about the things that are not boxes — a person, a credential, a contract, a build pipeline, a domain registration. The answers produce a short list. Most items on it are cheap to fix once they are written down, and the value of the exercise is almost entirely in having written them down before the night one of them is discovered by an outage. It is also worth accepting that some of them stay. Removing every one is not an engineering goal but an infinite regress, and a company that pretends otherwise ends up with an expensive architecture and no plan. The useful position is to know which ones you have chosen to keep, to have written down what you do when each of them goes, and to review the list when the system changes shape.","A single point of failure stops everything regardless of what else is duplicated. Why the real ones are people, credentials and jobs, not servers.",null,[11,14,17,20],{"slug":12,"name":13},"availability-zone","Availability Zone (AZ)",{"slug":15,"name":16},"blast-radius","Blast Radius",{"slug":18,"name":19},"disaster-recovery","Disaster Recovery",{"slug":21,"name":22},"multi-region","Multi-Region",[24,28,32,33,36,39,43,46,49,52,55,58],{"slug":25,"category":5,"name":26,"updated_at":27},"air-gapped-deployment","Air-Gapped Deployment","2026-09-09T03:30:02+00:00",{"slug":29,"category":5,"name":30,"updated_at":31},"autoscaling","Autoscaling","2026-09-08T21:32:36+00:00",{"slug":12,"category":5,"name":13,"updated_at":31},{"slug":34,"category":5,"name":35,"updated_at":31},"block-storage","Block Storage",{"slug":37,"category":5,"name":38,"updated_at":27},"bring-your-own-cloud","Bring Your Own Cloud (BYOC)",{"slug":40,"category":5,"name":41,"updated_at":42},"budget-alert","Budget Alert","2026-09-08T21:32:37+00:00",{"slug":44,"category":5,"name":45,"updated_at":27},"change-freeze","Change Freeze",{"slug":47,"category":5,"name":48,"updated_at":27},"control-plane","Control Plane and Data Plane",{"slug":50,"category":5,"name":51,"updated_at":42},"cost-allocation-tag","Cost Allocation Tag",{"slug":53,"category":5,"name":54,"updated_at":42},"cost-chargeback","Cost Chargeback",{"slug":56,"category":5,"name":57,"updated_at":42},"cost-observability","Cost Observability",{"slug":18,"category":5,"name":19,"updated_at":31}]