I solved a similar problem by 'chaining' the events using EventServiceProvider.php and triggering the next step in my various listeners. A->B/C->C->D

Different resources took different lengths of time to load as not all resources were reliable. My thought process was that I could start X number os threads per worker and as stuff was processed it would trigger the next thing in line to be done. Sometimes it's a linear progression and sometimes a single step will trigger some new jobs in parallel.

Balancing/tuning it was a bit of a pain, always changing the number of workers for a given queue (there were 4 in total) but Laravel Horizon appears to provide sufficient automation of that although I have not tested it on that particular project.

It's a bit of a pain to setup but allows for individual jobs to be processed or not (just commented out stuff that wasn't used at the time), allows for decreased execution time with Horizon and multiple worker machines.

Jobs were handled by RabbitMQ with a persistent queue and would typically have 500K to 5M in the queue at any given time across the queues. Not incredibly elegant, but that was the nature of this project as a single site could have 10s of thousands of pages and those pages could have hundreds of images each.

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Event;

class EventServiceProvider extends ServiceProvider
{

protected $listen = [

    // Two jobs that are triggered by one initialization routine that will execute in series,
    // fast process, 100s of thousands of jobs, only SpiderPage if status 200/OK
    // Since PageAdded was also used for updating, SpiderPage would look at the DB
    // and only attempt to download it if it hadn't been already (vs trying to remove
    // the SpiderPage item from the queue) so it was a minimal DB lookup

    'App\Events\PageAdded'       => [
        'App\Listeners\CheckPage',
        'App\Listeners\SpiderPage',
    ],

    // Single event that can be processed in parallel, triggered in CheckPage
    // very long process, millions of jobs

    'App\Events\QueueScreenshot' => [
        'App\Listeners\ScreenshotPage',
    ],

    // 100s of thousands, parallel, triggers 'PageAdded'
    // fast job, little network, got lots of worker threads

    'App\Events\SiteAdded'       => [
        'App\Listeners\CheckSite',
    ],

    // database intensive, only using one worker due to this or other parts
    //  slow down considerably, 100s of thousands of jobs

    'App\Events\PageDownloaded'  => [
        'App\Listeners\ScorePage',
    ],

    // variable job length from fast to very slow or timeout
    // depending on machine it's running on, get's more or less workers, 10s of millions

    'App\Events\QueueImage'      => [
        'App\Listeners\DownloadImage',
    ],

    // long process, millions of jobs, very high CPU/RAM usage, very little
    // network usage, only run on certain worker machines that have lots of RAM

    'App\Events\QueueImageScore' => [
        'App\Listeners\ScoreImage',
    ],

];