A 911-support portal’s recovery-time objective requires the back-end to resume serving within seconds of a worker failure, and sessions are already shared or stateless. Which HA pattern best matches that requirement?
Select an answer to reveal the explanation.
Short Explanation
Two open service windows recover faster than a closed spare you unlock after the line already formed. Active-active fits a tight recovery-time need when sessions are shared or stateless. A cold standby or a tarball is slower by design.
Full Explanation
When a 911-support portal's RTO demands resume within seconds and sessions are already shared or stateless, active-active instances best match the requirement. Multiple workers already serve traffic; losing one leaves others hot, so recovery does not wait on cold start, image pull, or manual promotion. Shared or tokenized session state is what makes that interchangeability safe.
A single primary with a backup tarball restored only after operators notice fails RTO—detection plus restore is minutes to hours, not seconds. Active-standby with a powered-off spare fails because boot and warm-up time dominate the outage window. One oversized instance with nightly snapshots fails both HA and RTO: snapshots protect data at best, not continuous request serving, and a single instance remains a single point of failure.
Exam caveat: active-active without health-aware load balancing or shared state can still strand clerks; pattern and state design travel together.
Operational check: kill one serving worker under load and measure time until error rate returns to baseline without manual intervention; it should be on the order of probe and failover seconds.
Active-active also supports rolling upgrades: drain one 911-support worker while peers keep answering. Pair it with health probes so failed instances leave rotation immediately. If RTO is seconds, cold spares and operator-driven restores are the wrong HA class regardless of how large the single primary VM is.