Active-Passive Architecture

Active-passive architecture uses a primary environment to serve production traffic while a standby environment is kept ready to take over after a failure. It improves availability and supports disaster recovery, but failover introduces detection, synchronization, and recovery-time considerations.

In an active-passive setup, the active instance handles normal production requests. The passive instance does not normally serve the production workload, but it is maintained sufficiently close to the active system that it can assume responsibility when required.

A failover mechanism detects that the primary is unavailable and redirects traffic or promotes the standby. This can be automated with health checks, a load balancer, DNS, a database failover mechanism, or an orchestration platform. The exact mechanism depends on the application architecture.

The standby can be hot, warm, or cold. A hot standby is already running and closely synchronized, allowing relatively fast recovery. A warm standby has some infrastructure running but may require additional startup or synchronization work. A cold standby is largely stopped or provisioned only after a failure, which generally increases recovery time.

Data consistency is a major concern. If the standby receives replicated data asynchronously, it can lag behind the primary, so a failure may cause some recently committed data to be unavailable. Synchronous replication can reduce that exposure but may introduce latency or availability trade-offs.

Two important recovery measures are RTO and RPO. Recovery Time Objective describes how quickly service should be restored, while Recovery Point Objective describes how much recent data loss the system can tolerate. The standby design, replication strategy, and failover automation should be chosen to meet those requirements.

Key points

• The primary serves normal traffic; the standby takes over after primary failure.
• Failover requires failure detection plus a mechanism for redirecting or promoting traffic.
• Hot, warm, and cold standby configurations differ mainly in readiness and recovery time.
• Replication strategy determines how much data might be lost during a failure.
• RTO measures recovery time; RPO measures acceptable data-loss exposure.

Interview questions

What is an active-passive architecture, and why would you use it?

An active-passive architecture has one primary system serving production traffic and a standby system prepared to take over if the primary fails. The standby normally does not handle the regular workload. A failover mechanism detects the problem and redirects traffic or promotes the standby. It is useful when service availability requirements justify maintaining redundant infrastructure.

What is the difference between hot, warm, and cold standby?

A hot standby is running and generally kept closely synchronized with the primary, so it can take traffic with little startup work. A warm standby has some infrastructure available but may need additional startup or synchronization before serving production traffic. A cold standby is largely inactive and requires more provisioning or startup after a failure. The choice affects recovery time, operational complexity, and cost.

How does data replication affect active-passive failover?

The standby needs a usable copy of the state required to continue serving requests. With asynchronous replication, the standby can lag behind the primary, so a failure may lose recently committed changes that had not replicated. Synchronous replication can reduce that window but can add latency and create availability trade-offs. The replication method should therefore be selected according to the application's RPO and consistency requirements.

How would you design failover for a Java backend service?

I would keep application instances as stateless as practical and place traffic management outside individual application processes. Health checks would distinguish an unhealthy primary from a transient dependency problem, while a load balancer, service-discovery layer, or orchestration mechanism would direct traffic to the standby. Stateful components such as databases would need their own replication and promotion strategy. I would define RTO and RPO first, automate failover where appropriate, and regularly test recovery rather than assuming the standby works.

What is split brain, and why is it dangerous in active-passive systems?

Split brain occurs when multiple nodes independently believe they are the active authority at the same time. In a stateful system, both nodes may accept writes, producing conflicting state or duplicate side effects. Preventing it can require quorum mechanisms, fencing, leases, or another authoritative coordination mechanism. The exact solution depends on which component is being failed over and how ownership is established.