{
  "schema_version": 2,
  "id": "operate/rs/databases/active-active/disaster-recovery/proxy-based",
  "title": "Proxy-based disaster recovery",
  "url": "https://redis.io/docs/latest/operate/rs/databases/active-active/disaster-recovery/proxy-based/",
  "summary": "Proxy-based disaster recovery for Active-Active databases.",
  "tags": [
    "docs",
    "operate",
    "rs",
    "rc"
  ],
  "last_updated": "2026-10-01T15:27:03+01:00",
  "page_type": "content",
  "content_hash": "14b7225894f70fd5f231fe0304133463e3a8c7aed2b8f55d72147a7259865bad",
  "sections": [
    {
      "id": "overview",
      "title": "Overview",
      "role": "overview",
      "text": "If you add a lightweight proxy software component between the clients and the Active-Active database, applications can dynamically route requests to the optimal endpoint.\n\nAdvantages:\n\n- Proxies provide proactive and reactive health check methods, such as polling target health periodically using either a TCP connection or an HTTP request, or monitoring live operations for errors.\n\n- Proxies can be configured to run Active-Active health checks, such as the lag-aware database availability requests.\n\n- If an Active-Active database member fails, a proxy can automatically detect the issue and redirect traffic to a healthy Active-Active database member without requiring DNS propagation delays or client disconnections. This enables fast, controlled failover and minimizes downtime.\n\nConsiderations:\n\n- If you do not use DNS to resolve the Active-Active database members' FQDNs:\n\n    - The proxies must have static IPs.\n\n    - If you add a new node to the cluster, you must configure the proxy with the new endpoint.\n\n    - A configuration syncer component is required to discover topology changes and reconfigure the proxy.\n\n- Proxies introduce latency.\n\n- Proxy failures can disconnect clients and cause disruptions."
    },
    {
      "id": "avoid-concurrent-access-across-replicas",
      "title": "Avoid concurrent access across replicas",
      "role": "content",
      "text": "If concurrent access across replicas must be avoided in every scenario, you can use a centralized proxy with a standby proxy instance for high availability.\n\nAdvantages:\n\n- Prevents concurrent access across replicas.\n\n- Failover and failback are simultaneous regardless of the Active-Active health check policy.\n\nConsiderations:\n\n- Although the proxy can be monitored with a watchdog and restarted in case of failure, this setup does not grant high availability for the proxy.\n\n- Limited scalability.\n\nThe following diagram shows a centralized proxy architecture with a standby proxy instance:\n\n![Diagram of a centralized proxy architecture with active and standby proxy instances routing to Active-Active database members](https://redis.io/docs/latest/images/active-active-disaster-recovery/centralized-proxy.svg)"
    },
    {
      "id": "co-locate-to-reduce-latency-and-improve-scalability",
      "title": "Co-locate to reduce latency and improve scalability",
      "role": "content",
      "text": "To reduce latency and improve scalability, you can use a proxy co-located in the application server.\n\nAdvantages:\n\n- Reduced latency.\n\n- Better scalability.\n\nConsiderations:\n\n- Failover and failback might not be simultaneous depending on the Active-Active health check policy.\n\nThe following diagram shows a co-located proxy architecture where each application server has its own proxy:\n\n![Diagram of co-located proxy architecture where each application server has its own proxy instance](https://redis.io/docs/latest/images/active-active-disaster-recovery/co-located-proxy-and-app.svg)"
    },
    {
      "id": "pool-proxies-for-scalability",
      "title": "Pool proxies for scalability",
      "role": "content",
      "text": "You can use a pool of active proxies to scale the routing layer. Application servers can balance new connections to the pool of proxies using a round-robin distribution algorithm, such as DNS-based round robin.\n\nAdvantages:\n\n- High availability without complex monitoring and failover solutions.\n\n- Flexible scalability of the routing layer.\n\nConsiderations:\n\n- Concurrent access across replicas is possible, but can be mitigated using database availability API requests.\n\nThe following diagram shows a pool of proxies:\n\n![Diagram of a pool of active proxy instances](https://redis.io/docs/latest/images/active-active-disaster-recovery/proxy-pool.svg)"
    }
  ],
  "examples": []
}