Observabilidade é feature de produto

Um cliente escreve: 'meu pedido sumiu'. O que acontece em seguida me diz mais sobre um sistema do que qualquer diagrama de arquitetura. Num sistema bem construído, alguém digita o id do pedido numa caixa de busca e, trinta segundos depois, tem a história completa: criado às 14:02, pagamento autorizado, reserva de estoque estourou o timeout, cancelamento compensatório disparado, email enfileirado mas devolvido. Na maioria dos sistemas que audito, o que acontece em seguida é uma investigação de duas horas em três dashboards e um console de banco, terminando em 'a gente acha que foi o provedor de pagamento'.

A diferença não é ferramenta. Os dois times têm logs e métricas. A diferença é que o primeiro tratou observabilidade como algo que o produto faz, não como algo que a plataforma fornece.

A pergunta para a qual você está construindo

Observabilidade tem um trabalho só: responder perguntas que você não sabia que ia fazer. Métricas respondem as perguntas que você previu. Alertas respondem as perguntas que você temia. Mas o ticket de suporte, a investigação de fraude, o 'por que esse tenant está lento', essas são imprevisíveis, e só um contexto rico, correlacionado e pesquisável responde.

Então o alvo do design é simples: dado qualquer identificador de negócio (id do pedido, do usuário, do tenant, da requisição), quanto tempo leva para reconstruir o que o sistema fez? Se a resposta é medida em minutos, você tem observabilidade. Se é medida em reuniões, você tem logs.

Três coisas que fazem funcionar

A primeira é um correlation id que sobrevive a toda fronteira. Ele é gerado na borda e vai preso em cada linha de log, cada mensagem de fila, cada chamada HTTP de saída, cada comentário de query se você puder pagar por isso. Sem ele, você tem eventos. Com ele, você tem uma história. Numa aplicação Next.js isso significa que o id nasce no middleware, atravessa server actions e API routes e é injetado no contexto do logger, não passado na mão.

A segunda é que identificadores de negócio são campos de primeira classe, não texto dentro da mensagem. Uma linha de log dizendo 'processando pedido 8812' é quase inútil. Uma linha com order_id como campo estruturado, ao lado de tenant_id e user_id, é pesquisável, filtrável e cruzável. Todo o valor está nos campos.

A terceira é que os eventos importantes são emitidos de propósito. Não 'entrou na função', mas 'pagamento autorizado', 'reserva falhou', 'estorno emitido'. Esses são eventos de domínio. São os mesmos eventos que o time de produto listaria se você perguntasse o que importa. Emitir eles como logs estruturados ou spans te dá uma linha do tempo de negócio de graça.

Por que isso pertence ao roadmap

Quando observabilidade é tratada como infraestrutura, ela não compete com nada e não ganha nada. Quando é tratada como feature, compete com outras features, e ganha mais vezes do que as pessoas esperam. Veja o que ela entrega: tickets de suporte resolvidos em minutos em vez de horas, incidentes com causa raiz encontrada no primeiro dia, padrões de fraude visíveis antes de virarem prejuízo, regressões de performance capturadas por tenant em vez de diluídas na média.

Num marketplace que revisei, o investimento de engenharia mais valioso do ano foi uma página interna que recebia um id de pedido e mostrava a linha do tempo dele. Não era glamouroso. Eliminou uma categoria inteira de escalação.

O mínimo que eu recomendo

Logs JSON estruturados com um conjunto estável de campos. Um correlation id da borda até o banco. Eventos de domínio emitidos explicitamente em cada transição de estado que importa para o negócio. Retenção longa o suficiente para investigar o mês passado, não só a noite passada. E uma ferramenta interna, por mais feia que seja, que transforma um id de negócio numa linha do tempo.

Isso é alguns dias de trabalho num sistema pequeno e se paga no primeiro incidente sério. O time de produto não vai pedir. Construa mesmo assim, e depois mostre o que ela faz. A partir daí, eles nunca mais vão deixar você tirar.