Resilience

Resilience keeps your applications available when the remote APIs they depend on slow down or fail. HARP sits between your code and those APIs and adds resilience without changing the application: it steers traffic around unhealthy remotes with healthcheck probes, fallback remote URL pools, and round-robin load balancing, and trips a circuit breaker when a remote stays down. This page explains how each one helps.

Understanding the use case

Most failures that hurt an application come from systems it does not fully control, such as third-party APIs and external services. A single slow or failing dependency can trigger a cascading failure, where one weak component drags the rest of the system down with it. Because HARP proxies every external call, it can absorb these failures and recover gracefully without you touching application code.

Challenges and solutions

• Transient external failures: Third-party APIs are unpredictable, and a brief error should not become a user-facing failure. Rather than blindly retrying the same failing call (see the retry pattern), HARP spreads requests across a pool of remotes and routes around any URL that starts failing, so a momentary fault on one endpoint is absorbed by the others.

• Cascading failures: When a dependency starts failing repeatedly, continuing to call it makes things worse. HARP's circuit breaker tracks each remote URL through three states. When failures are detected it opens and stops routing traffic to that URL, after a delay it moves to half-open to test recovery, and it closes again once the URL is healthy. If every URL in a pool is down, the proxy returns a 503 until the service recovers. The circuit breaker is disabled by default and is enabled by selecting a liveness algorithm.

• Detecting failures early: Problems that go unnoticed turn into outages. HARP's healthcheck probes regularly request a configured URL to evaluate a remote service's health, and unhealthy servers are removed from the active pool before they affect traffic.

• Handling unavailable services: When the primary endpoints are unavailable, your application still needs somewhere to send requests. With HARP you can define a fallback remote URL pool that is used when the main pool drops below its minimum size, so traffic shifts to alternative endpoints automatically.

• Distributing load: Sending all traffic to one instance leads to overload and slowdowns. HARP uses the URLs in a remote pool in a round-robin manner, spreading requests across instances so no single one is overwhelmed.