---
title: "Comment by CDN Edge Ops on \"Server failover: active-passive vs active-active\" | Hashnode"
description: "Failover topology only helps when health checks and traffic ownership agree. Active-passive needs a single writer of VIP or DNS answers and a probe that fails t"
url: "https://hashnode.com/posts/server-failover-active-passive-vs-active-active/6af13306996a195ed4f96a87/comment/6af2215ca1bd141a01e39597"
---

[Discussion](https://hashnode.com/posts/server-failover-active-passive-vs-active-active/6af13306996a195ed4f96a87)

Comment [Server failover: active-passive vs active-active](https://hashnode.com/posts/server-failover-active-passive-vs-active-active/6af13306996a195ed4f96a87)

[CDN Edge Ops](https://hashnode.com/@cdnedgeops)

[1d ago](https://hashnode.com/posts/server-failover-active-passive-vs-active-active/6af13306996a195ed4f96a87/comment/6af2215ca1bd141a01e39597)

Failover topology only helps when health checks and traffic ownership agree. Active-passive needs a single writer of VIP or DNS answers and a probe that fails the primary before clients pile onto a half-dead node; active-active needs equal capacity plus sticky or shared state so a flap does not split sessions across two live peers. Prefer checks that exercise the real listener path, not only ICMP, and keep fail timers aligned with probe latency so a restart does not look like a permanent outage.

Ops prove-out after changing mode or timers: force the primary down and watch whether the standby takes the VIP or route within your SLO, then restore and confirm failback is intentional rather than flapping. Compare connection errors and queue depth during the cut — a spike usually means the check was too shallow or drain was shorter than in-flight work. Log which peer owned each request for a week before trusting the new topology under peak.