Очереди задач — одна из тех вещей, которые настраивают один раз и боль­ше не тро­га­ют. Кон­фиг опи­сывает извест­ные по­то­ки фоно­вых ра­бот, деп­лой раска­тывает его, вор­керы подни­мают­ся и дела­ют своё дело. Так рабо­та­ет в по­дав­ляю­щем боль­шинст­ве про­ектов. А что если появ­ляется не­об­хо­ди­мость запус­кать мак­си­маль­но изо­ли­ро­ван­ные зада­чи, ко­то­ры­ми дол­жен управ­лять поль­зо­ва­тель, а не раз­работ­чик: соз­да­вать, за­пускать, оста­нав­ли­вать? Это еди­ни­ца, ко­то­рую надо изо­ли­ро­вать, по­яв­ля­ется и исчеза­ет между деп­лоя­ми, а единст­вен­ный спо­соб рас­сказать об этом сис­теме — от­ре­дак­тиро­вать кон­фиг и рас­ка­тать всё за­ново.

В Laravel Horizon доку­мента­ция закан­чи­вает­ся на конфи­ге и паре artisan-команд про то, как поднять супер­визо­ры, наст­роить ворке­ры, их масшта­биро­вание и указать очереди. А что, если нам нуж­но соз­дать свои собст­вен­ные очере­ди и их воркеры в ран­тайме? Об этом доку­мента­ция молчит. Но если про­читать ис­ход­ни­ки, выясня­ется, что конфиг — не единст­вен­ный источ­ник исти­ны.

Эта статья на приме­ре плат­фор­мы для email-рассылок рас­скажет про пост­рое­ние дина­мичес­ких очере­дей поверх стати­чес­ко­го конфига Laravel Horizon, исполь­зуя внут­рен­ние не­до­ку­мен­ти­ро­ван­ные ме­ха­низ­мы, кото­рые Horizon сам ис­поль­зу­ет внутри себя. Про архитек­туру с авто­мати­чес­ким восс­танов­ле­нием кон­сен­су­са, раз­ре­ше­нием оши­бок и оп­ти­ми­за­цией памя­ти для дол­го жи­ву­щих оче­ре­дей.