Learn
What is a single point of failure in software?
A SPOF in software is a file or module where failure doesn't stay contained — it cascades across the system. These files are structurally critical, often invisible, and they only reveal themselves when they break.
Not the same as infrastructure SPOF.
When most engineers hear “single point of failure,” they think of infrastructure: a single database server with no replica, a load balancer with no failover, a DNS provider with no backup. Infrastructure SPOFs are well-understood and have established mitigations — redundancy, failover, multi-region deployment.
Software SPOFs are different. They live inside your code. They're files or modules that sit at the center of your dependency graph — everything routes through them, everything depends on them, and if they fail, the failure cascades outward through dozens or hundreds of dependent files.
You can have perfectly redundant infrastructure and still have critical software SPOFs. Your database has three replicas, but the single ORM configuration module that every query passes through has no redundancy at all. If that file has a bug, all three replicas become equally unreachable.
What software SPOFs look like.
These are real patterns found in production codebases. Every team has them.
The Auth Middleware
A single authentication module that every route, every API endpoint, and every middleware chain passes through. If it fails, nothing in the system can verify identity — and every protected resource becomes inaccessible.
The Database Connection Pool
One shared connection utility that every service uses to talk to the database. If this file has a bug, every query in the system fails. Not just reads — writes, migrations, health checks, everything.
The Config Loader
A configuration module imported at startup by every service. If the config parser breaks or the file it reads is malformed, no service can start. The entire application is dead on arrival.
The Shared Types File
A TypeScript definitions file imported by 80% of the codebase. Any breaking change to a type here — even a rename — cascades through dozens or hundreds of files. It's not a runtime failure, but it's a build-time catastrophe.
How to identify SPOFs.
SPOF detection requires analyzing the structure of your dependency graph, not just reading the code. Four approaches work together.
In-Degree Centrality
Count how many files import this file. High in-degree means many files depend on it directly. But this alone misses transitive dependents — the files that depend on files that depend on the SPOF.
Betweenness Centrality
Measure how often a file sits on the shortest path between other files in the dependency graph. High betweenness means the file is a bridge — removing it disconnects parts of the system from each other.
PageRank
Apply the same algorithm Google uses to rank web pages, but on your dependency graph. Files that are imported by many important files rank higher. A file with high PageRank is structurally critical.
Blast Radius Analysis
Compute how many files break (directly or transitively) if this file fails. A file with a blast radius of 50+ is a SPOF regardless of what the centrality metrics say — the impact is too large.
Why SPOFs stay invisible.
Software SPOFs are invisible because they're structurally embedded. You can read the code and see that a file is important, but you can't see from reading it alone how many other files depend on it transitively. That information only exists in the dependency graph.
Most teams discover their SPOFs the hard way: a change to a “simple” utility file breaks the build in 30 places, or a bug in the auth middleware takes down every API endpoint simultaneously. The post-incident review reveals what should have been known beforehand.
Axiom Refract identifies SPOFs automatically by computing centrality metrics and blast radius for every file in your codebase. Files that cross the SPOF threshold are flagged with their affected zones and dependent counts — so you know the risk before the incident happens.
Find your single points of failure before they find you.
Upload your repository and get a complete SPOF manifest — every critical file, its blast radius, affected zones, and dependent count.