‘We have a backup’ means very little until you say which kind. Active-active and active-passive are different tradeoffs in cost, complexity and how fast you recover. Here’s how to choose.
Redundancy isn’t one thing. The two common models behave very differently when the primary dies, and picking the wrong one means paying for resilience you don’t actually get.
| Active-passive | Active-active | |
|---|---|---|
| Failover time | Seconds to minutes | Near-instant |
| Cost | Lower (idle standby) | Higher (all live) |
| Complexity | Lower | Higher (state sync, split-brain) |
| Spare capacity | Wasted until failover | Always used |
Match the model to the component. Stateless, throughput components (edges, packagers) suit active-active — they’re easy to run in parallel and benefit from the shared load. Stateful, correctness-critical components (a primary database) often use active-passive with a replica promoted on failure, because active-active writes invite split-brain.
A common, sensible pattern: active-active for the data plane (edges), active-passive with replicas for the stateful control plane. You get instant failover where it’s easy and safe promotion where it’s not.
For a national design, a warm-standby origin in a second metro (active-passive) is usually the pragmatic choice — it protects against a site or path loss without the cost and complexity of a fully active-active origin.
Talk to a team that runs a live operator, not just sells software.
