Active-Active vs. Active-Passive for Your Identity and Policy Layer

Active-passive is cheaper to run day to day, since the standby doesn't need to handle production load, but it shifts the cost into the failover moment itself: detection time, promotion time, and the risk that the standby has quietly drifted out of sync with the primary because nobody's watching it under real load. The failover you never test is the failover that fails when you need it.

If you go this route, schedule regular, real failover drills, not tabletop exercises, where you actually promote the standby and route production traffic to it, then measure how long it took and what broke.

Active-active removes the failover moment (there's no single point that has to notice failure and promote a standby) but it adds real, ongoing complexity: your policy decisions and identity state have to stay consistent across regions in something close to real time, or you risk a request being allowed in one region and denied in another for the same caller at the same moment. That consistency problem is the actual cost, and it's a permanent engineering burden, not a one-time setup cost.

This is usually worth it once you're operating at a scale where a full regional failure is a realistic scenario you plan for, not a hypothetical.

A downtime budget at 99% availability tolerates an active-passive setup with a slow, careful failover, but that downtime budget shrinks fast once you move toward 99.99% availability or tighter, where a manual or even semi-automated promotion process can burn through the whole allowance in a single incident¹. Decide your real availability target first, based on what your customers actually need and what you're contractually committing to, then choose the architecture that target requires, rather than defaulting to whichever pattern is more familiar to your team.

For example, a small B2B team with two engineers on call and a modest availability commitment might start with active-passive and run a real promotion drill every quarter. If a drill shows that detection and promotion take longer than the downtime budget allows, that result is the evidence for moving to active-active, not a vague sense that redundancy feels safer. A useful decision rule: pick the simplest pattern whose measured failover time fits inside the allowance your contracts imply, and revisit the choice when the commitment tightens.

Full regional outages get all the attention in failover planning, but partial degradation, your identity provider responding slowly rather than failing outright, is both more common and harder to handle well. A slow policy engine can make every request wait rather than fail cleanly, which is often worse for users than an outright outage they can at least detect and route around.

Build a specific test for this: inject artificial latency into your identity or policy service in a staging environment and watch what your APIs do. If they queue requests indefinitely instead of timing out and falling back to a cached decision or a safe default, that's a gap independent of which failover architecture you chose.

When the identity or policy service is unreachable, does the request get denied (fail closed, safer but can cause a broad outage from a single dependency failure) or allowed with a cached or default decision (fail open, keeps things running but weakens the guarantee during the outage)? This decision needs to be made deliberately and in advance, per endpoint if necessary, not discovered live during an incident when someone is under pressure to bring things back up.

Financial and destructive-action endpoints should almost always fail closed. Read-only, low-sensitivity endpoints are a more reasonable candidate for a fail-open exception, if you make that call before the outage rather than during it.

Settle these points before you pick a failover pattern:

• Your real availability target, based on what customers need and what you have committed to in contracts.
• Whether your team can run real failover drills that promote the standby and route production traffic to it.
• Whether policy decisions and identity state can stay consistent across regions in close to real time.
• How your APIs behave when the identity provider is slow instead of down, including timeouts and cached fallbacks.
• Which endpoints fail closed and which, if any, are allowed a fail-open exception, decided before an outage.