Uma das decisões mais simples de explicar e mais fáceis de esquecer é: nem tudo precisa acontecer enquanto o usuário espera a resposta. Correção de provas, envio de e-mail, geração de relatório — se não precisa ser instantâneo, não deveria travar a requisição.
A régua que uso
Pergunto sempre: o usuário precisa ver o resultado disso agora, na mesma tela? Se a resposta é não, viro Job e jogo numa fila. É assim que trato retenção de alunos inativos por e-mail e atualização de ranking no Simulado Solidário — nada disso trava a experiência de quem está estudando, mesmo com milhares de usuários simultâneos.
Um exemplo concreto: quando um aluno termina uma prova, a interface responde imediatamente com "prova enviada com sucesso" — mas a correção detalhada, o recálculo do ranking geral e o envio do e-mail de resultado acontecem depois, via fila. O aluno não fica esperando um processo que pode levar alguns segundos; ele já pode seguir navegando enquanto o Job roda em segundo plano.
O que isso evita
Sem essa disciplina, é fácil cair na armadilha de uma requisição que demora 8 segundos porque está enviando e-mail, gerando PDF e atualizando estatística tudo de forma síncrona. Jobs e Queues em Laravel resolvem isso de forma direta — o difícil não é a ferramenta, é lembrar de perguntar, toda vez, "isso realmente precisa rodar agora?"
Idempotência: o detalhe que ninguém lembra
Um Job que roda duas vezes por engano — por causa de um retry automático, por exemplo — não pode gerar dois e-mails de resultado ou cobrar duas vezes o mesmo pagamento. Esse é exatamente o mesmo cuidado que descrevo em integrações de pagamento: todo processamento assíncrono precisa ser seguro para rodar mais de uma vez sem causar efeito colateral duplicado.
