Juliana Dias de Oliveira Nascimento Mayrink; Gabriel Custódio Rangel

DOI: 10.22167/2675-6528-202601018

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

Aplicações baseadas no padrão “Backend-for-Frontend” (BFF) concentraram responsabilidades críticas na orquestração de fluxos entre o “front-end” e múltiplos serviços de “back-end”, o que tornou a identificação e a resolução de falhas em produção particularmente desafiadoras na ausência de dados observáveis. Analisou-se o impacto da implementação de mecanismos de observabilidade em uma aplicação BFF desenvolvida em Node.js, com foco na detecção e resolução de falhas percebidas pelo “front-end”. A metodologia adotada consistiu em um estudo de caso conduzido em ambiente real de produção, envolvendo a análise do cenário pré-intervenção, caracterizado por processos de diagnóstico manuais e reativos, e a posterior implementação de uma solução de observabilidade baseada em métricas, rastreamento distribuído e monitoramento de erros. Como parte do estudo, coletaram-se dados qualitativos por meio de formulário aplicado à equipe de desenvolvimento, antes e após a intervenção, bem como dados técnicos gerados pela plataforma de observabilidade. Os resultados indicaram melhoria significativa na capacidade de identificação da causa raiz dos problemas, redução do tempo necessário para análise de incidentes e aumento da visibilidade sobre falhas anteriormente não detectadas, especialmente aquelas representadas por códigos HTTP da família 4xx. Concluiu-se que a adoção de observabilidade no BFF contribuiu para um processo de resolução de falhas mais objetivo, eficiente e proativo, evidenciando a relevância dessa abordagem em arquiteturas orientadas a serviços.

Palavras-chave: Diagnóstico de falhas; Monitoramento de aplicações; Rastreamento distribuído; Sistemas distribuídos.

1. Introdução

No cenário atual do desenvolvimento de software, a transição para arquiteturas distribuídas, como os microsserviços, tem sido impulsionada pela busca por maior escalabilidade, resiliência e agilidade no desenvolvimento. Contudo, essa evolução introduz uma complexidade inerente à gestão e ao diagnóstico de sistemas, especialmente quando múltiplas camadas de serviço interagem para atender a uma única requisição de usuário. Nesse contexto, o padrão arquitetural “Backend-for-Frontend” (BFF) emergiu como uma solução estratégica, permitindo a criação de camadas de agregação de dados e orquestração de serviços otimizadas para as necessidades específicas de diferentes interfaces de usuário, sejam elas web, mobile ou outras (Newman, 2015). Embora o BFF ofereça benefícios significativos em termos de desacoplamento e personalização da experiência do usuário, ele também concentra responsabilidades críticas na orquestração de fluxos complexos, tornando-se um ponto focal para a manifestação de falhas que impactam diretamente o front-end.

A detecção e a resolução de falhas em ambientes de produção complexos, como aqueles que empregam o padrão BFF, tornam-se particularmente desafiadoras na ausência de dados observáveis. A observabilidade, que se distingue do monitoramento tradicional pela capacidade de inferir o estado interno de um sistema a partir de seus dados externos (métricas, logs e rastreamentos distribuídos), é fundamental para garantir a confiabilidade e a eficiência operacional em arquiteturas distribuídas (Beyer et al., 2016). Enquanto o monitoramento responde a “conhecidos desconhecidos”, a observabilidade busca desvendar “desconhecidos desconhecidos”, oferecendo uma compreensão mais profunda do comportamento do sistema. A ausência de métricas adequadas e de uma visão holística dos fluxos de requisição compromete diretamente a capacidade das equipes de desenvolvimento de identificar a causa raiz dos problemas, resultando em processos de diagnóstico reativos e ineficientes (Treynor et al., 2018).

Em muitas organizações, a ausência de mecanismos de observabilidade estruturados em aplicações BFF resulta em um cenário de diagnóstico de falhas predominantemente manual e reativo. Problemas de desempenho, lentidão ou indisponibilidade, frequentemente percebidos pelo usuário final, são reportados por meio de canais informais ou abertura de “tickets” de suporte, sem a existência de um histórico técnico estruturado ou dados quantitativos sobre latência, taxa de erro ou volume de requisições. Nesse contexto, a identificação da causa raiz depende, muitas vezes, de tentativas manuais de reprodução do erro em ambientes de desenvolvimento, que raramente replicam as condições de carga e instrumentação da produção. Tal abordagem leva a um tempo médio de resolução de incidentes (MTTR) elevado, com análises que podem se estender por horas ou até vários dias, envolvendo reuniões síncronas e coleta manual de informações. Além disso, falhas representadas por códigos HTTP da família 4xx, que indicam problemas do lado do cliente ou de validação, são frequentemente sub-representadas ou mal interpretadas por sistemas de monitoramento padrão, mascarando problemas críticos para a experiência do usuário e dificultando a priorização de intervenções técnicas.

Diante da complexidade inerente às arquiteturas BFF e das limitações demonstradas pelos processos de diagnóstico reativos e manuais, a implementação de práticas de observabilidade robustas torna-se imperativa para aprimorar a confiabilidade e a eficiência operacional. Este estudo, portanto, visa analisar o impacto da implementação de mecanismos de observabilidade em uma aplicação BFF desenvolvida em Node.js, com foco na melhoria da detecção e resolução de falhas percebidas pelo “front-end”, comparando o cenário de produção pré-intervenção com o cenário pós-implementação de uma solução abrangente baseada em métricas, rastreamento distribuído e monitoramento de erros.

2. Material e Métodos

A presente pesquisa foi delineada como um estudo de caso com abordagem aplicada, orientado pelos princípios da pesquisa-ação, visando analisar o impacto da implementação de mecanismos de observabilidade em um contexto real de desenvolvimento de software. Essa abordagem permitiu uma investigação aprofundada de um fenômeno contemporâneo em seu ambiente natural, combinando a aplicação prática de uma solução com a análise sistemática de seus efeitos. O estudo buscou compreender as mudanças no processo de detecção e resolução de falhas, comparando cenários pré e pós-intervenção.

O estudo foi conduzido em uma empresa de tecnologia de grande porte, focando em uma aplicação do tipo Backend-for-Frontend (BFF) desenvolvida em Node.js. Por razões éticas e de confidencialidade, o nome da empresa e detalhes sensíveis da arquitetura não foram divulgados. A aplicação BFF atua como uma camada intermediária crucial, orquestrando fluxos entre aplicações “front-end” internas e múltiplos serviços de “back-end”, sendo responsável por operações críticas relacionadas à concessão e gestão de crédito a parceiros comerciais.

A unidade de análise central foi a aplicação BFF em Node.js, observada em seu ambiente de produção. O período de estudo abrangeu a coleta de dados do cenário pré-intervenção, que incluiu a análise de “tickets” registrados em agosto, e a coleta de dados pós-intervenção, com um histórico aproximado de três meses de indicadores técnicos operacionais e a reaplicação de formulários em setembro. O delineamento metodológico buscou analisar o impacto da observabilidade na capacidade da equipe técnica de detectar, diagnosticar, priorizar e resolver falhas em produção.

A população para a coleta de dados qualitativos consistiu na equipe de desenvolvimento que atua diretamente sobre a aplicação BFF. Uma amostra por conveniência de três desenvolvedores foi selecionada para participar da pesquisa, respondendo a um formulário estruturado. Essa escolha visou obter percepções diretas de profissionais envolvidos no dia a dia da aplicação, cujas experiências eram cruciais para caracterizar o cenário de diagnóstico de falhas antes e depois da intervenção. Os entrevistados não participaram da elaboração deste trabalho, minimizando vieses.

Os instrumentos de coleta de dados incluíram um formulário qualitativo, aplicado antes e após a intervenção, composto por questões fechadas com escalas categóricas e do tipo Likert (Koo e Yang, 2025), além de uma questão aberta opcional. Este formulário, detalhado no Apêndice E do TCC original, visava registrar percepções sobre dificuldades de diagnóstico, esforço de investigação e tempo de resposta a incidentes. Adicionalmente, foram analisados documentos como “tickets” operacionais registrados antes da intervenção, e dados técnicos gerados pela plataforma de observabilidade Datadog.

A execução da pesquisa foi dividida em duas etapas principais. A primeira consistiu no levantamento e caracterização do cenário inicial, pré-intervenção, onde a aplicação não possuía métricas técnicas estruturadas ou rastreamento distribuído. O diagnóstico de problemas era reativo, baseado em relatos informais e tentativas manuais de reprodução de erros. Essa etapa envolveu a análise documental de “tickets” e a aplicação do formulário qualitativo aos desenvolvedores para documentar suas percepções sobre o processo de resolução de falhas.

A segunda etapa focou na implementação da solução de observabilidade na aplicação BFF. Utilizou-se a ferramenta Datadog para coletar métricas, rastreamento distribuído e monitoramento de erros. O Datadog Agent foi configurado como um “DaemonSet” em um cluster Kubernetes, capturando dados da aplicação e da infraestrutura. Essa instrumentação permitiu a coleta automática e padronizada de dados técnicos, como latência de requisições, códigos de resposta HTTP e volume de chamadas, sem intervenção manual durante a execução da aplicação (Datadog, 2024).

Uma decisão técnica crucial durante a implementação foi a instrumentação para rastreamento distribuído na aplicação BFF em Node.js, utilizando a biblioteca `dd-trace`. A inicialização do “tracer” ocorreu no ponto mais inicial do ciclo de execução da aplicação para garantir a instrumentação de todas as dependências. A configuração padrão da biblioteca foi ajustada para habilitar a injeção automática de contexto de “trace” em “logs” e a coleta automática de “traces” HTTP (Datadog, 2025).

Considerando o contexto específico da aplicação, onde falhas de validação e erros de contrato são frequentemente representados por códigos HTTP da família 4xx, o critério padrão de classificação de erro do “tracer” foi sobrescrito. Originalmente, apenas respostas com código HTTP igual ou superior a 500 eram consideradas erro. No entanto, para este estudo, qualquer resposta com código HTTP igual ou superior a 400 foi redefinida como erro, utilizando a opção `validateStatus` na inicialização do “tracer” (Datadog, 2025).

Essa redefinição do critério de erro, implementada com a versão 5.35 da biblioteca `dd-trace`, assegurou que falhas relevantes para a experiência do usuário, frequentemente mascaradas por códigos 4xx, fossem devidamente capturadas e rastreadas. Embora essa abordagem pudesse aumentar o volume de “traces” classificados como erro, ela foi considerada necessária para obter visibilidade completa sobre os fluxos problemáticos que impactam diretamente o consumo da API pelo “front-end”, maximizando a capacidade diagnóstica inicial do sistema.

Após a implementação da observabilidade, a coleta de dados pós-intervenção foi realizada. Os indicadores técnicos operacionais, como taxa de erro por “endpoint”, volume de requisições, métricas de latência (foco no percentil 95) e rastreamentos distribuídos correlacionando requisições do “front-end”, BFF e “back-end”, foram coletados continuamente por aproximadamente três meses. Paralelamente, o mesmo formulário qualitativo foi reaplicado aos três desenvolvedores para comparar suas percepções antes e depois da introdução dos dados observáveis.

A análise dos dados foi conduzida de forma combinada, integrando abordagens qualitativas e quantitativas. Os indicadores técnicos operacionais, obtidos da plataforma Datadog, foram utilizados para identificar padrões de falha, “endpoints” críticos e priorização técnica baseada em dados. Os indicadores de processo, derivados das respostas dos formulários e da análise de “tickets”, permitiram avaliar as mudanças na eficiência do diagnóstico e na capacidade da equipe de responder a incidentes (Saldaña, 2013).

A comparação entre os cenários pré e pós-intervenção não assumiu um caráter simétrico devido à ausência de métricas técnicas no período inicial. O foco da análise recaiu sobre a transição de um modelo de diagnóstico baseado em hipóteses e esforço manual para um modelo fundamentado em dados observáveis, avaliando os efeitos dessa transição no processo de trabalho da equipe. Essa abordagem permitiu compreender como a observabilidade influenciou a detecção, diagnóstico e resolução de falhas em produção.

Este estudo apresenta limitações inerentes ao seu delineamento, incluindo o número reduzido de participantes no formulário qualitativo e a ausência de métricas técnicas prévias à intervenção. Tais limitações, contudo, refletem o contexto real de aplicações que operam sem práticas de observabilidade e são consideradas parte do fenômeno analisado, não comprometendo os objetivos exploratórios e aplicados da pesquisa. A confidencialidade da empresa e dos participantes foi mantida, conforme os procedimentos éticos estabelecidos.

3. Resultados e Discussão

A análise dos resultados obtidos a partir da implementação de uma solução de observabilidade em uma aplicação Backend-for-Frontend (BFF) revelou uma transformação substancial nos processos de detecção, diagnóstico e resolução de falhas em ambiente de produção. Esta seção detalha as evidências qualitativas e quantitativas coletadas, contrastando o cenário pré-intervenção, marcado pela ausência de dados observáveis, com o cenário pós-intervenção, onde a disponibilidade de métricas e rastreamentos distribuídos permitiu uma abordagem mais proativa e eficiente.

No cenário pré-intervenção, a aplicação BFF operava sem mecanismos automatizados de observabilidade, uma condição que, conforme destacado por Beyer et al. (2016) e Treynor et al. (2018), compromete severamente a confiabilidade e a eficiência operacional de sistemas distribuídos. A inexistência de métricas de latência, taxa de erro, volume de requisições ou rastreamento distribuído impedia uma compreensão objetiva do comportamento do sistema em produção. Essa lacuna de dados resultava na ausência de um histórico técnico estruturado, inviabilizando análises quantitativas sobre falhas recorrentes, degradações de desempenho ou padrões de erro ao longo do tempo. A dependência de percepções subjetivas e relatos informais para a identificação de problemas criava um ambiente reativo, onde a equipe técnica era constantemente surpreendida por incidentes, em vez de antecipá-los ou diagnosticá-los com precisão.

A identificação de problemas, nesse contexto, baseava-se predominantemente em sinais indiretos, como a abertura de “tickets” pelo time de operações ou reclamações diretas de usuários. O processo de diagnóstico iniciava-se, tipicamente, com tentativas manuais de reprodução do erro em ambientes de desenvolvimento ou mesmo em produção. Essa abordagem, além de ser demorada e ineficiente, raramente replicava as condições exatas de carga e tráfego do ambiente produtivo, tornando a identificação da causa raiz um desafio complexo. A literatura em Engenharia de Confiabilidade de Sites (SRE), como a apresentada por Beyer et al. (2016), enfatiza a importância de métricas e telemetria para a saúde do sistema, e a ausência dessas ferramentas no cenário inicial do estudo ressalta a vulnerabilidade operacional da aplicação. A dependência de reprodução manual não apenas consumia um tempo valioso dos desenvolvedores, mas também introduzia riscos operacionais, especialmente em operações sensíveis como requisições do tipo “POST” ou “DELETE”, onde a execução efetiva poderia gerar efeitos colaterais indesejados, exigindo a intervenção de equipes de “back-end” para reversão.

As limitações desse processo eram particularmente evidentes em erros de validação ou inconsistências de dados, frequentemente representados por códigos HTTP da família 4xx, como 403 ou 422. Nesses casos, a análise dependia da extração manual e correta das requisições pelo usuário final, um procedimento que nem sempre era completo ou preciso. Quando a causa raiz não era identificada nessas etapas iniciais, o problema era escalado para o time de “back-end” sem informações claras sobre qual serviço específico havia falhado. A arquitetura BFF, ao centralizar a comunicação com múltiplos serviços, intensificava esse problema, pois a falta de visibilidade sobre o fluxo completo da requisição impedia a identificação do ponto exato de falha na cadeia de serviços. Essa dificuldade em correlacionar eventos entre diferentes componentes de um sistema distribuído é um desafio conhecido, e a observabilidade se propõe a mitigar essa complexidade, conforme discutido por Datadog (2024).

Do ponto de vista de evidências pré-intervenção, a ausência de métricas quantitativas impedia a mensuração do tempo médio de resolução de incidentes (MTTR) ou a frequência de falhas por “endpoint”. Os registros disponíveis limitavam-se a bilhetes de suporte, que ofereciam apenas uma análise qualitativa do processo. Um “ticket” específico, detalhado no Apêndice A do documento original, ilustra concretamente essas limitações. O incidente, iniciado em 14 de agosto, exigiu a solicitação de dados operacionais e tentativas manuais de reprodução do erro. A impossibilidade de reprodução isolada demandou comunicação assíncrona entre equipes, reuniões síncronas com usuários e interação com desenvolvedores de “back-end”. Somente em 18 de agosto, quatro dias após o início da investigação, foi possível identificar que o problema estava relacionado a respostas HTTP 403 de diferentes “endpoints” de “back-end” consumidos pelo BFF. Esse intervalo de quatro dias para a identificação da causa raiz evidencia o impacto direto da ausência de observabilidade sobre o tempo de diagnóstico e o esforço operacional, corroborando a visão de Treynor et al. (2018) sobre como a falta de métricas adequadas compromete a eficiência das operações.

Para complementar as evidências documentais, um formulário estruturado com escalas tipo Likert (Koo e Yang, 2025) foi aplicado a três desenvolvedores que atuam diretamente no BFF. Os resultados, apresentados na Tabela 1, Apêndice F, revelam uma convergência nas experiências relatadas, confirmando o cenário de baixa observabilidade.

Tabela 1. Respostas do formulário antes da implementação

Pergunta	Entrevistado A	Entrevistado B	Entrevistado C
Pergunta 1	Discordo	Discordo	Discordo totalmente
Pergunta 2	Frequentemente	Sempre	Sempre
Pergunta 3	Entre 1 dia e 4 dias	Entre 1 dia e 4 dias	Entre 2h e 6h
Pergunta 4	Discordo	Discordo	Discordo totalmente
Pergunta 5	Nunca	Nunca	Nunca

Fonte: Elaborado pela autora

Na Pergunta 1, todos os entrevistados discordaram da facilidade em identificar a causa raiz de erros em produção. Essa percepção reflete diretamente a falta de visibilidade e a dependência de métodos reativos, o que, em sistemas complexos como o BFF, pode levar a um aumento significativo do Mean Time To Repair (MTTR) e a uma degradação da experiência do usuário (Beyer et al., 2016). A dificuldade em pinpointar a origem de um problema em um ambiente distribuído sem ferramentas de rastreamento é um desafio central que a observabilidade busca resolver.

Em relação à Pergunta 2, todos indicaram que a reprodução manual de erros era “frequente” ou “sempre” necessária. Essa prática, além de ser demorada, é intrinsecamente falha, pois ambientes de desenvolvimento raramente replicam as condições de carga, dados e interações de sistemas de produção. A dependência de reprodução manual não apenas atrasa a resolução, mas também desvia recursos valiosos dos desenvolvedores de tarefas de inovação para atividades de depuração reativa.

A Pergunta 3 revelou que o tempo médio para entender a causa de um “ticket” relacionado a erro no BFF variava de “Entre 1 dia e 4 dias” para dois entrevistados e “Entre 2h e 6h” para um. Esses tempos são alarmantes em um contexto de negócios moderno, onde os Acordos de Nível de Serviço (SLAs) frequentemente exigem tempos de resposta e resolução muito mais curtos. A demora no diagnóstico impacta diretamente a disponibilidade do serviço e a satisfação do cliente, além de gerar custos operacionais elevados (Treynor et al., 2018).

Na Pergunta 4, todos os desenvolvedores discordaram ou discordaram totalmente da capacidade de visualizar com clareza quais serviços de “back-end” estavam envolvidos em uma requisição do BFF. Essa falta de visibilidade é um sintoma clássico de sistemas distribuídos sem rastreamento distribuído, onde uma requisição pode atravessar múltiplos serviços, tornando impossível para um desenvolvedor isolar o ponto de falha sem ferramentas adequadas (Datadog, 2024). A ausência de um mapa claro das dependências e do fluxo de dados impede uma análise sistêmica e proativa.

Finalmente, na Pergunta 5, todos os entrevistados afirmaram que suas análises de erros em produção “nunca” eram baseadas em dados observáveis, mas sim em hipóteses e inferências. Essa resposta é a mais contundente, pois demonstra a total ausência de uma cultura de tomada de decisão baseada em dados, o que é fundamental para a melhoria contínua e a resiliência de sistemas de software (Beyer et al., 2016). A dependência de inferências e hipóteses introduz um alto grau de incerteza e subjetividade no processo de resolução de problemas.

As respostas discursivas dos participantes aprofundaram esse diagnóstico, apontando impactos diretos sobre SLA, governança e esforço operacional, além da impossibilidade de atuação proativa na identificação de falhas. Um dos participantes (Entrevistado B) descreveu a dificuldade de identificar falhas que não se manifestam como erros de servidor, como códigos 403 ou 422, e a necessidade de reprodução manual. Outro (Entrevistado C) associou diretamente a ausência de observabilidade à degradação de SLA e a problemas de governança, enfatizando a incapacidade de ser proativo e a dependência da abertura de “tickets” por parte do usuário. Em conjunto, essas evidências qualitativas caracterizam o cenário pré-intervenção como um ambiente predominantemente reativo, manual e de baixa rastreabilidade, com elevada dependência de interação humana, ausência de dados estruturados para suporte ao diagnóstico e menor previsibilidade no tratamento de falhas em produção.

Cenário Pós-Intervenção: Disponibilidade de Dados Observáveis

Após a implementação da solução de observabilidade, os resultados do formulário pós-intervenção, apresentados na Tabela 2, Apêndice G, indicaram uma mudança consistente na percepção da equipe, evidenciando uma evolução significativa em aspectos centrais do diagnóstico, como a identificação da causa raiz, o tempo de análise e a dependência de reprodução manual de erros.

Tabela 2. Respostas do formulário após implementação

Pergunta	Entrevistado A	Entrevistado B	Entrevistado C
Pergunta 1	Concordo	Concordo	Neutro
Pergunta 2	As vezes	Raramente	As vezes
Pergunta 3	Menos de 2h	Menos de 2h	Menos de 2h
Pergunta 4	Neutro	Concordo	Concordo totalmente
Pergunta 5	Sempre	Frequentemente	Frequentemente

Fonte: Elaborado pela autora

Na Pergunta 1, que questionava sobre a facilidade de identificar a causa raiz de erros, observou-se uma inversão do padrão anterior: dois dos três entrevistados passaram a “Concordar” com a facilidade, e o terceiro migrou de “discordo totalmente” para uma posição “Neutro”. Essa mudança reflete diretamente o impacto da visibilidade proporcionada pela observabilidade. Com métricas, logs e rastreamentos distribuídos, os desenvolvedores agora possuem as ferramentas necessárias para investigar a origem dos problemas de forma mais eficiente, reduzindo a incerteza e o tempo gasto em depuração. Essa melhoria na capacidade diagnóstica é um pilar fundamental para a agilidade e a resiliência operacional, alinhando-se às melhores práticas de SRE (Beyer et al., 2016).

A Pergunta 2 registrou uma redução notável na frequência de reprodução manual de erros, com as respostas migrando de “sempre” e “frequentemente” para “às vezes” e “raramente”. Isso indica um impacto direto da observabilidade na redução de atividades manuais e reativas. A capacidade de inspecionar o comportamento da aplicação em produção, sem a necessidade de replicar cenários complexos, libera os desenvolvedores para focar em tarefas de maior valor agregado, como o desenvolvimento de novas funcionalidades ou a otimização de sistemas. A diminuição da dependência de reprodução manual não só acelera o processo de resolução de incidentes, mas também minimiza os riscos de introduzir novos problemas em ambientes de produção durante tentativas de depuração.

O resultado mais expressivo foi observado na Pergunta 3, referente ao tempo médio para entender a causa de um “ticket” de erro. Enquanto no cenário pré-intervenção o tempo variava entre horas e vários dias, no pós-intervenção todos os entrevistados indicaram um tempo inferior a duas horas (“Menos de 2h”). Essa drástica redução no tempo de diagnóstico tem implicações diretas e extremamente positivas sobre o cumprimento dos SLAs e a satisfação do cliente. Um MTTR significativamente menor é um indicador chave de um sistema operacionalmente maduro e bem observado, permitindo que a empresa responda a incidentes de forma ágil e minimize o impacto nos negócios. A capacidade de rapidamente identificar e resolver problemas é um diferencial competitivo crucial em arquiteturas de microsserviços e BFFs.

A Pergunta 4 apontou um aumento substancial na visibilidade sobre os serviços de “back-end” envolvidos em cada requisição. As respostas deslocaram-se da discordância para posições “Neutro”, “Concordo” e “Concordo totalmente”. Esse é um aspecto crítico em arquiteturas compostas por múltiplos serviços encadeados, como o BFF. O rastreamento distribuído, uma das capacidades centrais da observabilidade, permite que os desenvolvedores visualizem o fluxo completo de uma requisição através de todos os serviços envolvidos, identificando gargalos de desempenho ou pontos de falha em qualquer etapa da cadeia. Essa visibilidade holística é essencial para o diagnóstico eficaz em sistemas distribuídos, conforme enfatizado pela documentação do Datadog (2024).

Por fim, a Pergunta 5 evidenciou a transição de um modelo baseado em hipóteses para um orientado por dados: enquanto no pré-intervenção todos indicavam que suas análises “nunca” se baseavam em dados observáveis, no pós-intervenção as respostas migraram para “frequentemente” e “sempre”. Essa mudança de paradigma é fundamental para a construção de uma cultura de engenharia orientada por dados, onde as decisões sobre priorização de problemas, alocação de recursos e otimização de desempenho são embasadas em evidências técnicas concretas. Isso não apenas melhora a eficiência operacional, mas também fomenta uma abordagem proativa para a manutenção e evolução do sistema.

As respostas discursivas dos desenvolvedores reforçaram esses resultados qualitativos. Um participante relatou que “agora, como a gente tem o Trace, é muito fácil e muito rápido para mim”, descrevendo um fluxo direto no Datadog: “eu bato o olho e na hora eu sei se foi um 500, um 403, um 422, um 404 […] sei qual serviço falhou e inclusive eu sei porque falhou”. Essa citação ilustra a clareza e a rapidez no diagnóstico proporcionadas pelo rastreamento distribuído. Outro participante afirmou que “ter o Datadog funcionando corretamente melhorou muito a SLA e a resolução de problemas, e nos permite ser mais proativos na resolução de problemas”. Esses depoimentos evidenciam a percepção de valor da observabilidade na melhoria da eficiência operacional e na capacidade de adotar uma postura proativa, em contraste com a reatividade anterior. Exemplos documentados de “tickets” resolvidos após a intervenção, apresentados nos Apêndices B, C e D do documento original, demonstraram que incidentes passaram a ser solucionados em intervalos de poucos minutos a menos de uma hora, corroborando a redução do MTTR percebida nos formulários.

Um aspecto técnico relevante e crucial para a obtenção de visibilidade completa foi a decisão de classificar respostas HTTP 4xx como erro no rastreamento distribuído. Anteriormente, a instrumentação padrão da biblioteca `dd-trace` para Node.js considerava apenas respostas com código HTTP igual ou superior a 500 como erro, tratando os códigos 4xx como bem-sucedidos. Essa configuração padrão, conforme ilustrado na Figura 1, que apresenta o código fonte `dd-trace-js/index.d.ts` com `validateStatus`, e na Figura 2, que mostra o painel de “trace” antes da configuração, resultava em uma sub-representação significativa de problemas percebidos pelo “front-end”.

Figura 1. Código fonte dd-trace-js/index.d.ts com “validateStatus”

Fonte: Elaborado pela autora

Figura 2. Painel de “trace” do BFF antes da configuração 4xx como erro

Fonte: Elaborado pela autora

No contexto específico da aplicação BFF analisada, onde falhas de validação, inconsistências de dados e erros de contrato são frequentemente representados por códigos HTTP na faixa de 400 (com destaque para respostas 422), essa configuração padrão era insuficiente. Grande parte dos problemas relevantes para a experiência do usuário e para a estabilidade do fluxo de navegação manifestava-se como respostas 4xx, e não como falhas internas do servidor. A decisão de sobrescrever o critério de validação de “status” HTTP, utilizando a opção `validateStatus` na inicialização do “tracer” para considerar qualquer resposta com código HTTP igual ou superior a 400 como erro, foi fundamental. Essa alteração, conforme exemplificado na Figura 3, que apresenta o código com a inclusão de 4xx como erro, permitiu capturar 100% dos “traces” associados a falhas percebidas pelo “front-end”.

Figura 3. Código com inclusão de 4xx como error

Fonte: Elaborado pela autora

Após a implementação dessa sobrescrita, o volume de requisições 4xx registradas como erro aumentou para aproximadamente 17.800 eventos em um intervalo de uma semana, em comparação com os 11.600 eventos registrados anteriormente, conforme ilustrado na Figura 4, que mostra o painel de “trace” após a configuração.

Figura 4. Painel de “trace” do BFF após configuração 4xx como erro

Fonte: Elaborado pela autora

Esse aumento de aproximadamente 50% no volume de “traces” classificados como erro não refletiu um aumento real de falhas, mas sim a eliminação de uma sub-representação que mascarava problemas críticos para o usuário final. Essa abordagem, embora pudesse aumentar o volume de “traces” sinalizados como falha e, potencialmente, o “ruído” nos painéis de monitoramento, foi considerada aceitável e necessária para obter visibilidade completa sobre os fluxos problemáticos que impactam diretamente o consumo da API pelo “front-end”. A capacidade de rastrear e analisar esses erros de domínio é crucial para aprimorar a experiência do usuário e a estabilidade da aplicação, permitindo uma análise mais fiel da latência, propagação de erros e identificação de gargalos lógicos no fluxo de requisições.

Com base nos dados coletados após a intervenção, foi possível identificar mais de quinze “endpoints” com taxas de erro superiores a 20% em uma semana, incluindo “endpoints” críticos com alto volume de chamadas, conforme apresentado na Figura 5.

Figura 5. Painel de “endpoints” do BFF pós-intervenção

Fonte: Elaborado pela autora

A análise de latência no percentil 95 (P95) revelou ainda “endpoints” com tempos de resposta superiores a 20 segundos, evidenciando gargalos relevantes em fluxos específicos que, no cenário pré-intervenção, não eram perceptíveis de forma sistemática. Essa capacidade de identificar e priorizar “endpoints” problemáticos com base em dados concretos é um dos maiores benefícios da observabilidade. Permite que as equipes de desenvolvimento aloquem seus esforços de otimização de forma estratégica, focando nos pontos que geram maior impacto operacional e na experiência do usuário. A identificação de gargalos de latência, por exemplo, pode levar a otimizações de código, refatorações de arquitetura ou melhorias na infraestrutura, resultando em um desempenho geral aprimorado do sistema.

Dessa forma, o cenário pós-intervenção caracteriza-se pela transição de um modelo reativo e baseado em hipóteses para um modelo fundamentado em dados observáveis, no qual erros, latências e falhas de integração passam a ser analisados de maneira objetiva, rastreável e contextualizada. Essa transição não apenas aprimora a capacidade de detecção e resolução de falhas, mas também promove uma cultura de engenharia mais madura e proativa. A observabilidade, ao fornecer uma visão detalhada do comportamento interno da aplicação em tempo real, permite que as equipes identifiquem tendências, prevejam problemas e atuem preventivamente, minimizando o impacto de incidentes e melhorando a confiabilidade geral do sistema. A capacidade de correlacionar métricas de aplicação com metadados do ambiente, como nós e pods em um cluster Kubernetes, como descrito na Figura 11 (Datadog, 2024), é fundamental para a análise de fluxos distribuídos e para a compreensão do contexto operacional das falhas.

A implementação de observabilidade no BFF demonstrou um impacto direto e mensurável na detecção e resolução de falhas em ambiente de produção. A análise do cenário pré-intervenção evidenciou um processo de diagnóstico predominantemente reativo, manual e baseado em hipóteses, com baixa visibilidade sobre fluxos distribuídos e dependência significativa de reprodução de erros em produção. Após a intervenção, a disponibilização contínua de métricas, rastreamentos distribuídos e dados estruturados sobre erros permitiu uma mudança substancial nesse processo. Os resultados qualitativos indicaram melhora consistente na percepção da equipe quanto à facilidade de identificar a causa raiz, à clareza sobre os serviços envolvidos em cada requisição e à redução do tempo necessário para análise de incidentes. Esses achados foram corroborados pelos dados quantitativos, que evidenciaram maior visibilidade sobre “endpoints” críticos, aumento na detecção de falhas representadas por códigos HTTP 4xx e melhor compreensão do impacto operacional dessas falhas. A decisão de classificar respostas HTTP a partir de 400 como erro mostrou-se adequada ao contexto da aplicação analisada, ao ampliar a capacidade diagnóstica do sistema e permitir a captura de falhas relevantes para o consumo pelo “front-end”, anteriormente sub-representadas. Conclui-se, portanto, que a adoção de práticas de observabilidade no BFF não apenas aprimorou a identificação e a resolução de falhas, mas também contribuiu para um processo de tomada de decisão mais objetivo, orientado por dados e alinhado às necessidades reais da aplicação em produção.

4. Conclusão

Conclui-se que o objetivo foi atingido, demonstrando o impacto direto e mensurável da implementação de observabilidade em uma aplicação Backend-for-Frontend (BFF) para aprimorar a detecção e resolução de falhas em produção. A análise comparativa entre os cenários pré e pós-intervenção revelou uma transição de um processo de diagnóstico predominantemente reativo, manual e baseado em hipóteses para um modelo objetivo e orientado por dados. Houve uma melhora consistente na percepção da equipe quanto à facilidade de identificar a causa raiz, à clareza sobre os serviços envolvidos e à drástica redução do tempo de análise de incidentes para menos de duas horas. A decisão estratégica de classificar respostas HTTP a partir de 400 como erro no rastreamento distribuído foi crucial, ampliando a capacidade diagnóstica e revelando falhas relevantes para o front-end que antes estavam sub-representadas, como erros de validação e inconsistências de dados.

Este estudo, contudo, apresenta limitações inerentes, como o número reduzido de participantes no formulário qualitativo e a ausência de métricas técnicas prévias à intervenção, que refletem o contexto real de sistemas sem observabilidade. Para estudos futuros, sugere-se investigar o impacto da observabilidade em diferentes arquiteturas distribuídas, realizar uma análise quantitativa do MTTR em um período mais extenso e explorar a otimização das configurações de rastreamento para balancear a visibilidade com a redução de ruído, como a classificação de erros 4xx em cenários de maior maturidade operacional. A observabilidade deve ser vista como um processo contínuo de evolução, adaptando-se às necessidades do sistema.

Referências Bibliográficas

Beyer, B.; Jones, C.; Petoff, J.; Murphy, N.R. 2016. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, Sebastopol, CA, EUA.

Datadog. 2026. Tracing Node.js applications. Disponível em: <https://docs.datadoghq.com/tracing/trace_collection/dd_libraries/nodejs/\>. Acesso em: 31 jan. 2026.

Koo, M.; Yang, S.-W. 2025. Likert-type scale. Encyclopedia 5(1): 18. Disponível em: <https://doi.org/10.3390/encyclopedia5010018\>. Acesso em: 31 jan. 2026.

Newman, S. 2015. Backend for frontends. Disponível em: <https://samnewman.io/patterns/architectural/bff/\>. Acesso em: 14 set. 2025.

Saldaña, J. 2013. The Coding Manual for Qualitative Researchers. SAGE Publications, Thousand Oaks, CA, EUA.

Treynor, B.; Nukala, S.; Rau, V. 2018. Metrics that matter. ACM Queue 16(6). Disponível em: <https://research.google/pubs/metrics-that-matter/>. Acesso em: 14 set. 2025.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy