Fronteira de observabilidade no backend: o que cada camada deve emitir

O problema

Observabilidade ruim não é só falta de dado.

Às vezes é excesso de dado no lugar errado.

Você vê isso quando:

• handler loga entrada e saída completas
• use case loga a mesma decisão
• client externo loga o mesmo erro com outra mensagem
• job de retry registra tudo de novo

No fim, o incidente aparece cinco vezes.

E mesmo assim ninguém entende rápido:

• onde falhou de fato
• quem tomou a decisão errada
• qual parte é causa e qual parte é consequência

Modelo mental

Cada camada deveria emitir o tipo de sinal que ela realmente conhece.

Um jeito simples de pensar:

• borda: entrada, identidade do request, status de resposta
• aplicação: decisão relevante do fluxo e transição de estado
• integração: latência, erro técnico, contrato externo
• execução operacional: retry, timeout, fila, reprocessamento

O ponto não é impedir qualquer log fora do lugar.

É evitar que toda camada tente contar a história inteira sozinha.

Exemplo simples

Imagine um fluxo de criação de pedido.

O handler recebe a requisição.

O use case:

• valida regra
• reserva estoque
• chama antifraude
• publica evento

O que cada parte normalmente deveria emitir?

• handler: request id, actor, resultado HTTP
• use case: pedido aprovado, negado ou degradado
• antifraude: timeout, latência, código de erro traduzível
• publisher: sucesso ou falha de publicação

Se todas logarem o payload inteiro do pedido e a mesma mensagem “falha ao processar pedido”, você gerou repetição, não clareza.

O erro comum

O erro comum é tratar observabilidade como “coloca mais log”.

Isso costuma gerar:

• PII vazando onde não precisava
• custo alto de armazenamento
• busca confusa em incidente
• métrica inflada sem semântica

Outro erro comum é concentrar tudo numa camada só.

Quando só a borda loga, você perde detalhe técnico.

Quando só a integração loga, você perde impacto de negócio.

O que normalmente ajuda

Observabilidade melhor costuma nascer de algumas decisões simples:

• definir qual camada é dona do log estrutural principal
• registrar decisão de negócio só onde a decisão acontece
• traduzir erro técnico antes de subir para cima
• separar métrica operacional de métrica de produto

Também ajuda responder:

• este log serve para investigação?
• esta métrica serve para alerta?
• este evento serve para auditoria?

Quando tudo tenta servir para tudo, nada serve bem.

Como um senior pensa

Quem já investigou produção de verdade costuma perguntar:

• onde eu quero descobrir a causa raiz?
• onde eu quero medir impacto?
• que sinal preciso para acionar alerta sem ruído?
• o que não preciso registrar porque só vai duplicar contexto?

Essa conversa parece pequena.

Mas muda bastante a operabilidade do backend.

Ângulo de entrevista

Esse tema aparece em backend, incidentes, integrações e system design.

O entrevistador quer ver se você entende:

• que observabilidade é desenho, não só ferramenta
• que cada camada tem contexto diferente
• que ruído operacional também é falha de arquitetura

Resposta forte costuma soar assim:

“Eu separaria o que cada camada deve emitir. A borda registra contexto do request, a aplicação registra decisão relevante, e a integração registra falha técnica e latência. Se todas tentarem contar a história inteira, você ganha duplicação e perde clareza.”

Takeaway direto

Observabilidade boa não faz cada camada falar mais.

Faz cada camada dizer só o que ela realmente sabe.