A single point of failure is any one component whose failure, on its own, brings down the entire system, and finding these hidden dependencies is the first move in designing anything meant to survive a fault. The concept is deceptively simple but the hunt is not, because SPOFs hide in the parts nobody thinks about: the shared power feed both servers plug into, the one switch every cable passes through, the single account that unlocks everything. This guide defines the term, walks through how to track SPOFs down in a SCADA system, and shows how each redundancy pattern targets a specific class of them, including why redundancy that still shares one component only solves half the problem.
Single Point of Failure (SPOF) in one line: A single point of failure, or SPOF, is a component within a system that has no backup, so its failure by itself causes the whole system to fail. SPOFs can be hardware, software, network paths, power sources, data stores, or even people and credentials. Eliminating a SPOF means adding redundancy so that no single failure can take the system down, and SPOF analysis, the systematic search for these weak links, is the foundation of every high-availability and disaster-recovery design.
Finding single points of failure is a discipline of asking, for every element in a system, what happens if this one thing dies right now. The obvious candidates are the boxes on the diagram, but the dangerous SPOFs are usually the shared resources that the diagram does not draw. Two redundant servers offer no protection if they share a single power feed, because one tripped breaker takes both down at once. Two network paths give no resilience if they both run through the same switch, the same conduit, or the same upstream router. The failure everyone forgets is the one they assumed was safe because it had never failed before.
In a SCADA system the search runs across several layers. At the power layer, look for a single utility feed, one uninterruptible power supply, or one power strip feeding devices meant to back each other up. At the network layer, look for a single switch, a single communications path to the field, one firewall, or a single internet uplink. At the compute and data layer, look for one historian holding the only copy of history, one polling engine, or one database server. And at the human layer, look for a single credential store, one administrator who alone knows how to recover a system, or one vendor without whom nothing can be fixed. Each of these is a SPOF until it is duplicated, and mapping them honestly is more valuable than any single piece of redundant hardware.
Redundancy is not one thing; it is a family of patterns, and each pattern removes a particular class of single point of failure rather than all of them at once. An N+1 arrangement adds one spare to a set of N working units, so it survives the loss of any single unit, which suits power supplies, pumps, or servers where one extra unit covers a single failure economically. A 2N arrangement fully duplicates everything, so an entire parallel system stands ready, which removes SPOFs that N+1 leaves behind, such as a shared bus or a shared controller that a single spare still depends on. Geographic redundancy goes further and duplicates across separate locations, which is the only pattern that removes site-level SPOFs like a building fire, a regional power loss, or a flooded control room.
The critical insight is that redundancy which still shares one component is only partial, and that shared component becomes the new single point of failure. Two servers with automatic failover are useless against a failure of the one storage array they both mount, the one network switch they both connect through, or the one power circuit they both draw from. This is why SPOF analysis must chase the dependency all the way down: it is not enough to duplicate the servers if the thing underneath them is still singular. Real high availability comes from removing the last shared element in the critical path, and each layer you fail to duplicate quietly caps the reliability of every layer you did.
Distributed control operations are unusually rich in single points of failure because the system stretches from a field device across a network to a central platform, and any link in that chain can be singular. A remote well site with one communications gateway, one cellular modem, and one antenna has three stacked SPOFs on its uplink alone; lose any of them and the site goes dark to the control room even though the equipment keeps running. The site's power feed, its one PLC, and the single path its data takes back to the centre are all worth mapping, because remote sites are exactly where a quiet failure can go unnoticed until someone drives out to investigate.
Moving the supervisory platform to the cloud removes a large and often invisible SPOF that on-premise systems carry: the single on-site server room, with its lone air conditioner, one power circuit, and one building that a fire or flood can eliminate in an hour. A platform such as Merobix runs the central layer across multiple availability zones so that no single machine, rack, or facility is a point of failure for supervision, and edge gateways buffer data locally so a dropped field link does not lose readings. That shifts the operator's SPOF hunt to where it belongs, the field connection and the site itself, where adding a second communications path or a backup power source removes the dependencies that remain. The lesson is the same at every scale: resilience is only as good as the last shared component you were willing to duplicate.
A classic example is two redundant servers that both plug into the same power strip: the servers are duplicated, but the power strip is not, so one tripped strip takes both down. Other common SPOFs are a single network switch every cable passes through, one historian holding the only copy of data, a single internet uplink, or one administrator who alone knows how to recover a system. Anything with no backup whose loss stops the whole system qualifies.
You add redundancy so that no single failure can take the system down, then verify that the redundant elements do not secretly share a component. Duplicating servers only helps if they do not depend on one storage array, one switch, or one power circuit, so SPOF analysis chases each dependency to the bottom. The pattern you choose, whether N+1, full 2N duplication, or geographic redundancy, depends on which class of failure you need to survive.
Yes, and this is the most common mistake in resilient design. Redundancy that still shares one component just moves the single point of failure to that shared element, whether it is a common power feed, a single network path, or one storage array underneath both nodes. True high availability requires removing the last shared component in the critical path, which is why SPOF analysis matters more than simply buying duplicate hardware.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.