Failsafe Mechanism in Direct Mode
While the Lunar Interceptor includes a built-in failsafe mechanism to ensure uninterrupted API traffic routing, users of Direct Mode must implement their own failsafe mechanism.
A robust failsafe mechanism combines error tracking, conditional routing, and timers to address connectivity issues with the proxy or API gateway. These components work together to minimize downtime and provide flexibility in routing traffic. Let’s explore these elements and their application in a practical workflow.
Error Detection and Indicators
Error detection is the cornerstone of a failsafe mechanism. This involves monitoring responses for issues, using specific error indicators such as response headers or status codes. For instance:
- Error Indicators: Custom headers or HTTP response attributes signal problems with the proxy.
- Connection Failures: Inability to establish a connection to the proxy or gateway triggers error handling logic.
To effectively address errors:
- Define clear conditions for detecting errors (e.g., timeouts, error headers).
- Ensure that the system distinguishes between proxy-related issues and provider-related issues.
Managing Errors and Activation Thresholds
Once errors are detected, an Error Counter tracks consecutive failures. This counter ensures that occasional, transient errors don’t trigger unnecessary rerouting. Key considerations include:
- Max Error Threshold: Set a threshold for consecutive errors before activating the failsafe. For example, allow five consecutive errors before switching traffic routing.
- Error Handling Logic: This logic determines actions based on the error counter, such as incrementing the counter or initiating rerouting when the threshold is exceeded.
Example:
- If Error Counter < Max Error Threshold: Continue attempting to use the proxy.
- If Error Counter ≥ Max Error Threshold: Activate a cooldown period.
Cooldown Period and Request Routing
The Cooldown Timer plays a critical role in preventing repeated failures by temporarily redirecting traffic away from the proxy. During the cooldown period:
- All requests are sent directly to the original provider.
- The timer prevents immediate retries that could exacerbate issues.
To implement this:
- Define the cooldown duration based on the system’s tolerance for delays and recovery time.
- Ensure that the timer resets only after successful reconnection or a defined idle period.
Integrating Components into the Workflow
Here’s how these components come together:
- Initial Request Handling:
- Attempt to route the request through the proxy.
- If the cooldown timer is active, route directly to the original provider.
- Connection Failure:
- If the connection to the proxy fails, increment the error counter and initiate rerouting if necessary.
- Response Evaluation:
- Check for error indicators in the proxy response.
- Reset the error counter on successful responses.
- Error Handling and Cooldown Activation:
- When the error counter reaches the threshold, activate the cooldown timer to prevent repeated failures.
Configuration Parameters
| Parameter | Purpose | Default Value |
|---|---|---|
| Error Indicators | Define criteria for identifying proxy-related errors. | Customizable |
| Max Error Threshold | Maximum number of consecutive errors allowed. | 5 |
| Cooldown Duration | Duration for which traffic bypasses the proxy. | 10 seconds |
| Error Counter | Tracks the number of consecutive failures. | 0 |