Compartilhar contexto entre request e job

O problema

Request entra.

O backend decide algo.

Depois dispara um job.

Nesse ponto, quase sempre existe contexto que ainda importa:

• tenant_id
• correlation_id
• origem do disparo
• prioridade
• versão de regra
• motivo operacional

O erro comum é não decidir isso direito.

Daí o sistema cai em um destes caminhos:

• variável global
• contexto implícito de framework
• singleton compartilhado
• job consultando metade do estado depois “porque consegue”

Tudo isso parece funcionar até a primeira investigação séria.

Modelo mental

Job não continua um request.

Job começa um novo momento de execução.

Então ele precisa receber contexto suficiente para:

• executar a ação
• ser auditável
• ser reprocessável
• ser investigável

Isso não significa carregar tudo.

Significa carregar o contexto certo.

Exemplo simples

Imagine um request que aprova um pedido e agenda emissão de nota.

O job de nota talvez precise:

• order_id
• tenant_id
• correlation_id
• requested_by
• issued_under_policy_version

Ele provavelmente não precisa:

• headers completos
• payload inteiro do request
• sessão inteira do usuário

Quando você manda contexto demais, o job vira caminhão de acoplamento.

Quando manda contexto de menos, o job vira caixa-preta.

O erro comum

O erro comum é achar que observabilidade resolve tudo depois.

Sem contexto mínimo no payload do job, você acaba com:

• logs sem ligação clara com a origem
• retries opacos
• reprocessamento sem semântica
• job que precisa refazer lookup demais para descobrir por que existe

Outro erro comum é serializar o request inteiro “para garantir”.

Isso geralmente só leva sujeira adiante.

O que normalmente ajuda

Ajuda separar o que o job precisa em três grupos:

• identidade do alvo
• identidade do contexto operacional
• metadado mínimo de rastreio

Na prática, costuma ficar algo como:

• ids relevantes
• correlation id
• tenant ou escopo
• motivo/versão/prioridade quando isso muda a execução

Isso costuma ser suficiente para manter clareza sem transportar lixo.

Como um senior pensa

Quem já precisou debugar fluxo assíncrono de verdade costuma perguntar:

• se esse job falhar amanhã, vou entender de onde ele veio?
• se eu reprocessar, consigo preservar o contexto importante?
• esse campo é necessário para executar ou só veio junto por conveniência?
• estou carregando dependência oculta do request para dentro do job?

Essa conversa reduz bastante gambiarra invisível.

Ângulo de entrevista

Esse tema aparece em backend, filas, jobs, tracing e incidentes.

O entrevistador quer ver se você entende:

• que job assíncrono precisa de contrato próprio
• que contexto demais e contexto de menos quebram coisas diferentes
• que rastreabilidade e reprocessamento dependem de propagação explícita

Resposta forte costuma soar assim:

“Eu não tentaria compartilhar contexto via variável global ou request local storage. Preferiria enviar no payload do job só a identidade do alvo e o contexto operacional mínimo, como tenant, correlation id e versão da política quando isso afetar a execução.”

Takeaway direto

Contexto entre request e job não deve ser mágico.

Deve ser explícito o suficiente para o fluxo continuar compreensível.