Laravel: filas, jobs e scheduler sem complicar

A regra de ouro é esta: o request HTTP deve responder em milissegundos. Tudo o que demore — enviar emails, gerar PDFs, exportar CSVs, chamar APIs externas — vai para fora do request. No Laravel isto é quase trivial com jobs e o queue worker, e resolve a maioria dos problemas de lentidão que vejo em aplicações PHP.

O meu setup padrão começa simples: driver database para projetos pequenos, que dispensa infraestrutura extra, e Redis a partir do momento em que há volume. Cada job é escrito para ser idempotente — se correr duas vezes, o resultado é o mesmo — e traz retries e backoff para falhas transitórias. O método failed() regista o que precisa de atenção humana, em vez de a falha morrer em silêncio.

Por cima disto vem o scheduler, que evita um caos muito comum: uma entrada única de cron a correr schedule:run, e todas as tarefas declaradas no código. Limpeza de dados temporários, envio de resumos diários, sincronizações noturnas — tudo legível num ficheiro, em vez de 15 linhas cron espalhadas por um servidor que ninguém documenta.

Há um anti-padrão que vejo muitas vezes, e convém desmontar: lógica de negócio escondida dentro de jobs gigantes. O job deve orquestrar — chamar services pequenos e testáveis — não ser um contentor onde se atira tudo o que não cabe noutro lado. Filas não são um caixote para código mau; são uma ferramenta de responsividade.

Usas estas três peças bem, e o utilizador deixa de esperar pelo spinner. Que, no fundo, é o único resultado que ele repara.