Prototype failover queue

[taylorotwell]

This allows falling back to a failover queue if the primary queue connection for a job is down. The failover can be configured per queue connection and can contain multiple fallback connections.

Configuration has symmetry with how mail failover transports are configured:

// config/queue.php

'failover' => [
    'driver' => 'failover',
    'connections' => [
        'redis',
        'sync',
    ],
],

[bilfeldt]

Nice and straightforward implementation — this simple fallback loop is a clean solution and probably sufficient in many scenarios.

That said, it might be worth considering a Circuit Breaker pattern for this. It would prevent the application from repeatedly attempting operations on connections that are likely to fail, improving both resilience and performance under degraded conditions.

This pattern could also generalize nicely beyond this specific use case. We have several areas in the application where multiple drivers or connections can be configured, and introducing a shared, higher-level abstraction (similar to our \Illuminate\Support\Manager class) for managing fallbacks and circuit-breaking behavior could be a great addition to the framework overall.

Concept

1. Define a trigger threshold — e.g. a given number of consecutive failures within a certain timeframe causes the driver/connection to be marked as failing.
2. Define a retry strategy — after a cooldown period (fixed or exponential backoff), the system can periodically retry the failed driver to see if it has recovered.
3. Track state transitions — connections move between closed (healthy), open (failing), and half-open (testing recovery) states automatically based on observed results.
4. Skip failing connections — while in the open state, the system avoids using that connection and immediately falls back to the next available option.