Once you decide a system needs a second node, you face a design choice about how those two nodes cooperate: does the backup sit idle waiting for the primary to fail, or do both carry live work and cover each other? Those two modes are called active-passive and active-active, and the choice shapes throughput, how fast failover happens, and how hard the system is to keep consistent. This guide compares the two modes, lays out the tradeoffs each brings, and explains which suits the supervisory workloads that SCADA systems run, where it pairs naturally with the hot-standby concept at the mode level.
Active-Active vs Active-Passive in one line: Active-passive and active-active describe how a redundant pair shares work. In active-passive, one node handles all the load while the other stands by idle, ready to take over on failure, so half the capacity is held in reserve. In active-active, both nodes carry live load simultaneously and each can absorb the other's share if one fails, so no capacity sits idle. Active-passive is simpler and easier to keep consistent, while active-active offers more usable throughput and often faster failover at the cost of greater complexity in keeping both nodes in agreement.
In an active-passive design, one node is the primary and does all the real work while the second node, the passive standby, runs but handles no live traffic. The standby watches the primary through a heartbeat and stays synchronised so that if the primary fails, it can promote itself and take over the whole load. Until that moment it produces nothing useful in terms of throughput; its entire job is to be ready. This is the classic hot-standby arrangement, and its great virtue is simplicity, because at any instant only one node is authoritative, so there is never a question of two nodes disagreeing about the current state.
The costs of active-passive are capacity and, sometimes, failover time. Because the standby carries no load, you are paying for a full second node that contributes nothing until a failure, which can feel wasteful when hardware is expensive. Failover also takes a moment: the standby must detect the primary is gone, decide to take over, and bring services fully online, and how long that takes depends on how warm the standby was kept. A hot standby that mirrors state continuously fails over in seconds, whereas a colder standby that must load state or start services takes longer. The tradeoff is deliberate: you accept idle capacity and a brief switchover in exchange for a design that is easy to reason about and hard to corrupt.
In an active-active design, both nodes carry live load at the same time, and work is distributed between them while both are healthy. Nothing sits idle, so the pair delivers more usable throughput than an active-passive pair of the same hardware, and because both nodes are already running real traffic, the loss of one can be absorbed by the survivor with little or no cold-start delay, which tends to make failover faster and less visible. For workloads that are hungry for capacity or that cannot tolerate even a short switchover pause, active-active is attractive precisely because the surviving node is already doing the job.
The price of active-active is consistency and complexity. When two nodes are both accepting work and both changing shared state, you must guarantee they agree, or you risk conflicting updates, split-brain conditions where each node believes it is the sole survivor, and subtle data corruption. Solving this requires coordination mechanisms such as shared storage, distributed locking, or a consensus protocol, and it requires careful handling of the case where the nodes lose contact with each other but not with clients. There is also a capacity trap: if both nodes normally run near full load, losing one leaves the survivor unable to carry the combined demand, so a genuinely fault-tolerant active-active pair must each run below half capacity, which erodes the throughput advantage that motivated the design. Active-active gives more and fails over faster, but it demands engineering discipline that active-passive does not.
SCADA supervisory servers are a workload where active-passive is often the natural fit, for reasons rooted in how the system behaves. A supervisory node polls field devices, drives alarms, and maintains a live process image, and having exactly one authoritative source of that process image at any instant is a genuine advantage, because operators and downstream systems should never see two servers reporting slightly different values for the same tag. An active-passive pair with a hot standby preserves that single-authority model while still surviving a node failure, and the throughput of polling and displaying is rarely the bottleneck that would push a design toward active-active.
Active-active still earns its place in the parts of a modern control stack that behave more like web services than like a polling engine. A cloud SCADA platform serving dashboards, APIs, and historian queries to many users across many field sites is exactly the kind of read-heavy, horizontally scalable workload where running several nodes under load makes sense, both for capacity and for seamless failover when one node is lost. A platform such as Merobix can run its user-facing and data-serving tiers active-active across availability zones for scale and resilience, while the state that must stay singular is coordinated behind them. The practical rule is to match the mode to the workload: keep the authoritative process image on an active-passive pair where single authority matters, and run the scalable serving tiers active-active where capacity and instant failover matter more.
In active-passive, only one node carries load while the other stands by idle until it needs to take over, so half the capacity is held in reserve. In active-active, both nodes carry live load at once and each can absorb the other's share on failure, so no capacity sits idle. Active-passive is simpler to keep consistent, while active-active offers more throughput and often faster failover but demands careful coordination between the nodes.
No. Active-active gives more usable capacity and can fail over faster, but it introduces the hard problem of keeping two live nodes consistent, with risks of split-brain and conflicting updates that active-passive avoids by design. For workloads where having a single authoritative state matters more than raw throughput, such as a SCADA process image, active-passive is often the better choice. The right mode depends on the workload rather than on which sounds more advanced.
Not if you want true fault tolerance. If both nodes normally run near full load, losing one leaves the survivor unable to carry the combined demand, so a properly fault-tolerant active-active pair must each run below half capacity to absorb a failure. That headroom requirement erodes the apparent throughput advantage, which is why active-active is chosen for scalability and fast failover rather than for simply doubling usable capacity.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.