Alta Disponibilidade em Microsserviços: o Caso da Plataforma Fury do Mercado Livre

Thiago Veiga Lima; Vinicius Santos Andrade

DOI: 10.22167/2675-6528-202602380

Artigo derivado de Trabalho de Conclusão de Curso (TCC), com conteúdo baseado no trabalho original do aluno e adaptado ao formato editorial da Revista E&S com apoio da ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege para síntese e organização textual.

Resumo

A escalabilidade e a resiliência de plataformas de software representam desafios centrais para empresas de tecnologia que operam em larga escala. Investigou-se como a plataforma interna de desenvolvimento Fury, criada e mantida pelo Mercado Livre, implementou mecanismos de alta disponibilidade (HA) em um ecossistema de microsserviços que engloba mais de 30.000 serviços rodando em 100.000 instâncias em produção. A pesquisa combinou revisão bibliográfica sobre padrões de resiliência (circuit breaker, retry com backoff exponencial, bulkheads e rate limiting), análise documental de publicações técnicas do Mercado Livre e levantamento de campo aplicado a 20 engenheiros e tech leads que utilizam ou gerenciam aplicações na plataforma. Os resultados indicaram que o Fury reduziu significativamente a carga cognitiva dos times de desenvolvimento ao abstrair camadas de infraestrutura, automatizar pipelines de integração contínua e entrega contínua (CI/CD) e oferecer estratégias de deploy como blue-green com rollback imediato. A observabilidade nativa, contudo, foi avaliada como apenas parcialmente suficiente pela maioria dos respondentes, evidenciando uma lacuna que a organização vem endereçando com integração a ferramentas de mercado. Concluiu-se que o modelo de Internal Developer Platform (IDP) adotado pelo Mercado Livre é um exemplo de como práticas de DevOps, microsserviços e multicloud podem ser combinadas para sustentar disponibilidade elevada em ambientes de alta complexidade operacional. Essa visão sistêmica da disponibilidade é uma contribuição relevante para a literatura sobre IDPs.

Palavras-chave: Alta Disponibilidade; DevOps; Fury; Internal Developer Platform; Microsserviços.

1. Introdução

A confiabilidade de serviços digitais deixou de ser um diferencial competitivo para se tornar uma exigência básica do mercado. Em plataformas de comércio eletrônico e serviços financeiros que operam vinte e quatro horas por dia, sete dias por semana, a indisponibilidade de um componente pode significar perda direta de receita, erosão da confiança do consumidor e, em casos extremos, impactos regulatórios. Este cenário sublinha a importância crítica de sistemas robustos capazes de manter a operação contínua mesmo sob condições adversas.

O Mercado Livre, reconhecido como o maior ecossistema de comércio eletrônico e serviços financeiros da América Latina, exemplifica este desafio. Com operações em dezoito países e mais de cem milhões de usuários ativos, sua estrutura exige que os times de engenharia gerenciem dezenas de milhares de microsserviços interdependentes. Estes serviços estão constantemente sujeitos a picos de demanda imprevisíveis, especialmente durante eventos como o Dia do Consumidor ou a Black Friday. Assegurar a funcionalidade contínua nesta escala demanda mecanismos sofisticados para alta disponibilidade.

Nesse contexto altamente complexo e dinâmico, a questão central desta pesquisa foi: como uma plataforma interna de desenvolvimento consegue garantir alta disponibilidade em escala de dezenas de milhares de microsserviços, mantendo a produtividade de mais de 15.000 engenheiros? Este desafio evidencia a necessidade de abordagens sistemáticas para construir plataformas de software resilientes em uma escala excepcional.

Alta disponibilidade (HA) é definida como a capacidade de um sistema de permanecer operacional por um determinado percentual de tempo dentro de um período de referência, geralmente expresso em ‘noves’. Por exemplo, 99,9% de disponibilidade equivale a aproximadamente oito horas e quarenta minutos de indisponibilidade por ano, enquanto 99,99% reduz esse número para cerca de cinquenta e dois minutos (Tanenbaum e Van Steen, 2016). Os fundamentos teóricos da HA remontam ao teorema CAP, formulado por Brewer (2000) e formalizado por Gilbert e Lynch (2002), que estabelece que nenhum sistema distribuído pode garantir simultaneamente consistência total, disponibilidade total e tolerância a partições de rede. Arquiteturas orientadas à alta disponibilidade tendem a privilegiar disponibilidade e tolerância a partições, aceitando eventual inconsistência, modelo conhecido como BASE (Basically Available, Soft State, Eventually Consistent). A engenharia de confiabilidade de sites (SRE) consolidou práticas como a definição de Service Level Objectives (SLOs), Service Level Indicators (SLIs) e orçamentos de erro, que permitem equilibrar velocidade de lançamento de funcionalidades com a manutenção da confiabilidade do serviço (Beyer et al., 2016).

A adoção de arquiteturas de microsserviços trouxe padrões de resiliência amplamente documentados. O circuit breaker interrompe chamadas a serviços com falha e retorna respostas de fallback, evitando propagação em cascata (Nygard, 2007; Fowler, 2014). O retry com backoff exponencial repete chamadas com intervalos crescentes, com adição de jitter para evitar o fenômeno thundering herd (Amazon Web Services, 2023). Bulkheads isolam pools de recursos por dependência e rate limiting protege serviços de picos de tráfego abusivo (Richardson, 2018). O conceito de Internal Developer Platform (IDP) emergiu como resposta à complexidade operacional dos ambientes de microsserviços, oferecendo uma camada de autoatendimento que permite aos desenvolvedores criar, implantar e monitorar aplicações sem interagir diretamente com a infraestrutura subjacente (Humanitec, 2023). A estratégia multicloud, que envolve o uso simultâneo de provedores como AWS e GCP, complementa esse modelo ao aumentar a disponibilidade por redundância geográfica e reduzir o risco de vendor lock-in (Gartner, 2022).

A relevância do tema extrapola os limites da empresa estudada, pois entender como esses padrões de resiliência se materializam em uma plataforma de uso real, em escala real, é um exercício valioso tanto para pesquisadores quanto para profissionais que precisam tomar decisões de arquitetura no dia a dia. Do ponto de vista acadêmico, o trabalho se insere na interseção de múltiplas disciplinas exploradas ao longo do MBA em Engenharia de Software da USP/ESALQ: microsserviços, DevOps, orquestração de containers com Kubernetes, observabilidade e monitoramento, infraestrutura como código e cloud computing. Assim, este trabalho analisou como o Mercado Livre enfrentou o desafio da alta disponibilidade ao construir a plataforma interna Fury, investigando os padrões de resiliência empregados, os resultados obtidos em campo e as lições que esse caso oferece à engenharia de software contemporânea.

2. Material e Métodos

A presente pesquisa caracterizou-se, quanto à sua natureza, como aplicada, uma vez que se orientou para a solução de um problema prático relacionado à implementação de alta disponibilidade em ambientes de microsserviços. Em termos de abordagem, adotou-se um delineamento predominantemente qualitativo, complementado por elementos quantitativos na etapa de análise dos dados coletados por meio de questionário. No que concerne aos objetivos, o estudo classificou-se como exploratório-descritivo, buscando explorar a plataforma Fury, que possui documentação pública limitada, e descrever sistematicamente seus mecanismos de resiliência (Gil, 2017).

A estratégia de pesquisa empregada foi o estudo de caso único incorporado, conforme proposto por Yin (2015). A plataforma Fury, desenvolvida e mantida pelo Mercado Livre, constituiu a unidade primária de análise. Esta escolha justificou-se pela singularidade do caso, dada a ausência de outra plataforma interna de desenvolvimento na América Latina que apresente escala e maturidade comparáveis, tornando-a um objeto de estudo relevante para a engenharia de software.

Para a coleta de dados, utilizaram-se três fontes complementares, visando à triangulação e ao aumento da validade interna da pesquisa. A primeira fonte consistiu em uma revisão bibliográfica abrangente, que incluiu livros, artigos científicos e documentação técnica especializada sobre alta disponibilidade, padrões de resiliência e plataformas internas de desenvolvimento.

A segunda fonte de dados envolveu a análise documental de publicações técnicas divulgadas pelo próprio Mercado Livre. Foram examinados artigos publicados no Medium Engineering (Martins, 2024), apresentações realizadas em conferências públicas, como a PlatformCon 2023, e repositórios de código aberto mantidos pela organização. Esta abordagem permitiu compreender as estratégias e implementações da plataforma Fury a partir de materiais oficiais.

A terceira fonte de dados foi um levantamento de campo, realizado por meio da aplicação de um questionário estruturado. Este instrumento foi direcionado a profissionais que utilizam ou gerenciam aplicações na plataforma Fury no Mercado Livre. O questionário buscou coletar percepções e informações diretas dos usuários sobre a operacionalização da alta disponibilidade.

O instrumento de coleta de dados consistiu em um questionário estruturado, cujo conteúdo integral encontra-se detalhado no Anexo A do trabalho original. A aplicação do questionário ocorreu de forma digital, utilizando a plataforma Google Forms, entre os meses de fevereiro e abril de 2026. Este método garantiu a padronização da coleta e a facilidade de acesso aos participantes.

Participaram do levantamento de campo vinte profissionais do Mercado Livre, incluindo engenheiros de software e tech leads ou project leaders. O questionário foi composto por sete questões que abordaram aspectos como o perfil e o tempo de experiência dos respondentes com a plataforma Fury, os padrões de resiliência identificados, a avaliação da facilidade de implementação de alta disponibilidade em comparação com a construção do zero, os desafios técnicos enfrentados, a suficiência das ferramentas de observabilidade nativas e as métricas consideradas vitais para a saúde das aplicações.

A análise dos dados coletados foi realizada em duas etapas. Os dados de natureza quantitativa, obtidos a partir das questões fechadas do questionário, foram submetidos a estatística descritiva simples, com o cálculo de frequência absoluta e percentual. Esta abordagem permitiu quantificar a distribuição das respostas e identificar tendências gerais.

Os dados qualitativos, provenientes das respostas abertas do questionário, foram submetidos à análise de conteúdo temática, conforme a metodologia de Bardin (2016). Por meio dessa técnica, identificaram-se categorias emergentes a partir da recorrência de temas e conceitos nas respostas dos participantes. A triangulação entre as três fontes de dados — revisão bibliográfica, análise documental e levantamento de campo — foi empregada para fortalecer a validade interna das conclusões da pesquisa.

Os cuidados éticos foram observados rigorosamente durante todas as etapas da pesquisa. O estudo foi conduzido em conformidade com a Resolução CNS nº 510, de abril de 2016, do Conselho Nacional de Saúde. A pesquisa enquadrou-se nas exceções dos incisos I e VII do artigo 1º da referida resolução, por utilizar informações coletadas de forma anônima em ambiente profissional, garantindo a privacidade e a confidencialidade dos participantes.

3. Resultados e Discussão

A investigação sobre a plataforma Fury do Mercado Livre revelou um conjunto robusto de estratégias e mecanismos que sustentam a alta disponibilidade em um ecossistema de microsserviços de grande escala. Os achados indicam que a plataforma atua como uma camada de abstração eficaz, reduzindo a carga cognitiva dos desenvolvedores e automatizando processos críticos de infraestrutura e deploy. A pesquisa combinou a análise de publicações técnicas da empresa com um levantamento de campo junto a 20 engenheiros e tech leads, proporcionando uma visão multifacetada da implementação e percepção dos padrões de resiliência. Os resultados confirmam a relevância do modelo de Internal Developer Platform (IDP) para gerenciar a complexidade operacional inerente a ambientes distribuídos, ao mesmo tempo em que apontam para desafios persistentes, especialmente no campo da observabilidade nativa.

Histórico e contexto de criação do Fury

A evolução da plataforma Fury é intrinsecamente ligada ao crescimento exponencial do Mercado Livre, que em 1999 operava sobre uma arquitetura monolítica com centenas de servidores e um único banco de dados. Essa estrutura, embora funcional inicialmente, tornou-se um gargalo severo, resultando em deploys semanais com congelamento de código, testes lentos e conflitos entre equipes (Martins, 2024). A migração para microsserviços por volta de 2010 e o lançamento da MeliCloud, a primeira infraestrutura como serviço interna, representaram um avanço significativo, com mais de 1.400 instâncias implantadas diariamente e 17.500 instâncias gerenciadas. Contudo, a MeliCloud introduziu uma heterogeneidade excessiva, onde cada equipe definia sua própria infraestrutura, dificultando a consistência e a padronização.

Essa experiência levou à formulação de um princípio central para o design do Fury: permitir que um desenvolvedor tenha uma aplicação em produção com apenas três cliques. Lançada em 2015, a plataforma interna de desenvolvimento Fury materializou esse princípio, buscando abstrair a complexidade da infraestrutura e padronizar o ciclo de vida do software. Essa abordagem visava não apenas aumentar a produtividade dos engenheiros, mas também garantir que os mecanismos de alta disponibilidade fossem incorporados de forma intrínseca ao processo de desenvolvimento e operação, facilitando a escalabilidade e a resiliência do ecossistema de microsserviços.

Arquitetura e componentes principais

O Fury opera como uma Internal Developer Platform (IDP) abrangente, que abstrai a totalidade da cadeia de criação, configuração, deploy e monitoramento de aplicações. A interação com a plataforma é realizada por meio de uma interface web e uma Command Line Interface (CLI), simplificando o acesso e a gestão para os desenvolvedores. O conceito organizacional central é o “Scope”, que representa um ambiente de execução simplificado dentro de um provedor de nuvem, seja para desenvolvimento, homologação ou produção. Ao criar um scope, o Fury provisiona automaticamente componentes essenciais como load balancers, grupos de autoscaling e instâncias, além de configurar logs, métricas e alertas, tudo de forma transparente para o usuário.

A plataforma atua como uma camada de abstração crucial entre as aplicações dos desenvolvedores e os serviços externos, incluindo provedores como AWS, GCP e a infraestrutura on-premises do Mercado Livre. As aplicações não se comunicam diretamente com esses serviços de nuvem; em vez disso, uma camada anti-corrupção é empregada para prevenir o lock-in, facilitar atualizações de versão e permitir a troca de provedores sem a necessidade de alterações no código da aplicação (Martins, 2024b). Essa arquitetura simplificada, mas poderosa, é fundamental para a manutenção da alta disponibilidade, pois isola as aplicações da complexidade subjacente da infraestrutura.

O Release Process, implementado desde 2018, é um componente vital do Fury, gerenciando mais de 26.000 repositórios e executando automaticamente sete validações de qualidade a cada integração. Essas validações incluem verificação de dependências, modelo de branching, cobertura de testes e análise de credenciais hardcoded, garantindo a integridade e a segurança do código. Em 2024, a plataforma já processava mais de 30.000 deploys por dia através desse pipeline (Carvalho, 2024), demonstrando a capacidade de entrega contínua em larga escala. Os indicadores operacionais da plataforma em 2024 são notáveis, com mais de 30.000 microsserviços em produção, mais de 100.000 instâncias de produção, mais de 15.000 engenheiros utilizando a plataforma e mais de 26.000 repositórios gerenciados, além dos 30.000 deploys diários.

Mecanismos de alta disponibilidade no Fury

A alta disponibilidade no Fury não é uma funcionalidade isolada, mas uma propriedade emergente de um design sistêmico que incorpora resiliência em três camadas interconectadas: infraestrutura, deploy e aplicação. Na camada de infraestrutura, o autoscaling automático é o mecanismo mais proeminente. Quando um scope é criado, a plataforma configura grupos de autoscaling que ajustam o número de instâncias com base em métricas como CPU, memória e volume de requisições, de forma transparente para o desenvolvedor. Essa gestão de autoscaling foi desenvolvida internamente para suportar uma solução multi-vendor, sem depender exclusivamente de serviços específicos de provedores de nuvem (Martins, 2024b). A distribuição de cargas de trabalho por múltiplos availability zones complementa o autoscaling, assegurando que a falha de um datacenter não comprometa a disponibilidade do serviço.

Na camada de deploy, o Fury oferece diversas estratégias para garantir a continuidade das operações durante as atualizações. Entre as cinco estratégias disponíveis (All-in, Blue-Green, Canary, Safe Deploy e Migration), a Blue-Green é a escolha padrão para serviços críticos. Ela cria um novo ambiente em paralelo, migra o tráfego gradualmente e permite um rollback imediato sem downtime. O Safe Deploy é uma variação que monitora métricas continuamente e automatiza decisões de rollback quando anomalias são detectadas, reforçando a resiliência do processo de implantação. Essas estratégias são cruciais para manter a disponibilidade elevada, minimizando o impacto de novas versões.

Na camada de aplicação, os padrões de resiliência amplamente reconhecidos na literatura são disponibilizados como primitivas nativas da plataforma. O circuit breaker interrompe chamadas a serviços com falha, retornando respostas de fallback e prevenindo a propagação em cascata (Nygard, 2007; Fowler, 2014). O retry com backoff exponencial repete chamadas com intervalos crescentes, adicionando jitter para evitar o fenômeno thundering herd (Amazon Web Services, 2023). Bulkheads isolam pools de recursos por dependência, e rate limiting protege serviços de picos de tráfego abusivo (Richardson, 2018). A separação de aplicações críticas em scopes independentes funciona como um bulkhead em nível de infraestrutura, garantindo que problemas em um scope não afetem os demais. Esses padrões, integrados na plataforma, são essenciais para a robustez dos microsserviços.

Observabilidade e monitoramento

A observabilidade, definida como a capacidade de inferir o estado interno de um sistema a partir de suas saídas externas, é um pilar indissociável da alta disponibilidade. Sem visibilidade adequada sobre o que ocorre em produção, mesmo os designs de resiliência mais sofisticados podem falhar silenciosamente por longos períodos antes de serem detectados (Majors, Fong-Jones e Miranda, 2022). O Fury oferece, de forma nativa, monitoramento de métricas de infraestrutura, incluindo CPU, memória, tráfego, latência e taxa de erros. Além disso, a plataforma centraliza logs e permite a configuração de alertas, com integrações a ferramentas de mercado como DataDog, New Relic e OpsGenie. O monitoramento se estende a regras de negócio específicas, como picos no tempo de processamento de pagamentos, fornecendo uma visão abrangente da saúde das aplicações.

Evolução para multicloud e GenAI

A estratégia multicloud do Fury abstrai os provedores subjacentes, como AWS e GCP, apresentando aos desenvolvedores uma interface unificada e independente da infraestrutura utilizada. Esse design tem implicações diretas para a alta disponibilidade, pois a distribuição de cargas de trabalho entre provedores distintos reduz o risco de que um incidente em um provedor específico afete toda a operação. A abstração multicloud é viabilizada pelo uso de Kubernetes para orquestração de containers, Terraform para provisionamento de infraestrutura como código e uma camada proprietária de automação que incorpora as convenções e políticas de segurança do Mercado Livre. Atualmente, cerca de 20% da infraestrutura ainda opera fora do Fury, no que é denominado mundo Off-Fury, gerenciado por ferramentas de Infraestrutura como Código para manter conformidade e visibilidade (Martins, 2024b).

O próximo passo anunciado pela empresa é a integração com inteligência artificial generativa (GenAI), em parceria com a OpenAI, para criar soluções disruptivas no ecossistema de desenvolvimento. Essa iniciativa visa utilizar a IA na otimização de rotas de tráfego, na detecção preditiva de anomalias e na geração automática de código com padrões de resiliência embutidos. Essas tendências se alinham com o conceito de AIOps (Artificial Intelligence for IT Operations), que busca automatizar e otimizar as operações de TI por meio de inteligência artificial, prometendo avanços significativos na manutenção da alta disponibilidade e na eficiência operacional da plataforma Fury.

Perfil dos respondentes

O levantamento de campo foi conduzido com 20 profissionais do Mercado Livre entre fevereiro e abril de 2026. A maioria dos respondentes, 16 (80%), eram engenheiros de software ou desenvolvedores, enquanto 4 (20%) eram tech leads ou project leaders. Em relação ao tempo de experiência com a plataforma Fury, a predominância de respondentes com menos de um ano de uso reflete o rápido crescimento do quadro de engenharia do Mercado Livre e o ciclo contínuo de onboarding de novos colaboradores. No entanto, a presença de 4 (20%) profissionais com mais de três anos de experiência e 2 (10%) com experiência entre um e três anos forneceu perspectivas valiosas sobre a evolução e os desafios da plataforma ao longo do tempo, enriquecendo a análise qualitativa dos mecanismos de resiliência.

Padrões de resiliência identificados

Ao serem questionados sobre os padrões de resiliência mais eficazes na plataforma Fury, os respondentes puderam selecionar múltiplas opções, revelando a percepção de uso e a proeminência de cada mecanismo. Os padrões Retry com Backoff e Rate Limiting foram os mais citados, mencionados por 15 dos 20 respondentes, o que corresponde a 75% das menções. O Circuit Breaker foi identificado por 13 respondentes (65%), enquanto Bulkheads foi citado por 9 (45%) e Fallback Strategies por 7 (35%). Esses dados indicam que Retry com Backoff e Rate Limiting são os primeiros mecanismos de proteção com os quais os novos usuários do Fury interagem, enquanto Bulkheads e Fallback Strategies exigem uma maturidade maior de uso da plataforma para serem plenamente percebidos e utilizados pelos desenvolvedores.

A facilidade de implementação de alta disponibilidade no Fury, em comparação com a construção de soluções do zero, foi avaliada com uma média de 4,6 em uma escala de 1 a 5, onde 5 representa “muito fácil”. Apenas um respondente atribuiu nota 3, justificando com dificuldades na gestão de timeouts, enquanto os demais atribuíram notas 4 ou 5. Essa percepção geral de alta facilidade sugere que o Fury simplifica substancialmente a implementação de mecanismos de alta disponibilidade. Um dos respondentes sintetizou essa percepção ao afirmar que, até o momento da pesquisa, a plataforma havia garantido alta disponibilidade sem que sua equipe precisasse de ações adicionais, evidenciando a eficácia da abstração e automação oferecidas pelo Fury.

Desafios técnicos e lacunas observadas

As respostas abertas sobre os desafios técnicos revelaram três categorias principais. A primeira, mencionada por quatro respondentes, foi a curva de aprendizado e a necessidade de conhecimento aprofundado do ecossistema. Por ser uma plataforma proprietária com documentação interna, o Fury apresenta uma curva de aprendizado sem referências externas abundantes, ao contrário de serviços de nuvem públicos como AWS, Azure e GCP. Esse isolamento do conhecimento é uma consequência paradoxal do sucesso da abstração: quanto mais a plataforma oculta a complexidade, menos o desenvolvedor compreende o que fazer quando ocorrem problemas, o que pode dificultar a resolução de incidentes.

A segunda categoria de desafios foi a complexidade do ambiente distribuído. Um respondente destacou que lidar com um ambiente altamente distribuído, repleto de dependências e com deploys contínuos, é o maior obstáculo. Qualquer lentidão ou falha em um serviço pode desencadear um efeito cascata em outros, evidenciando que, embora os padrões de resiliência sejam eficazes, eles gerenciam a complexidade inerente aos sistemas distribuídos, mas não a eliminam completamente. A interconexão dos microsserviços exige uma compreensão aprofundada das interações para mitigar riscos de falhas em cascata, mesmo com a implementação de padrões de resiliência.

A terceira categoria de desafios foi a observabilidade e o diagnóstico de incidentes. Entre os 20 respondentes, 13 (65%) afirmaram que a visibilidade nativa do Fury é apenas parcial e que, ocasionalmente, precisam recorrer a ferramentas externas para obter a visibilidade necessária. Quatro respondentes (20%) avaliaram a observabilidade como totalmente suficiente, enquanto dois (10%) a consideraram limitada. Os principais pontos de atrito citados foram a descentralização de logs e a latência entre as camadas de abstração. Um respondente apontou que a descentralização e a escassez de logs dificultam a identificação da causa raiz, enquanto outro mencionou o tempo de resposta entre as inúmeras camadas e abstrações do Fury como um desafio recorrente. Esses achados sugerem a necessidade de evolução do rastreamento distribuído (distributed tracing) na plataforma, lacuna que ferramentas como OpenTelemetry poderiam endereçar para melhorar a capacidade de diagnóstico.

As métricas consideradas vitais pelos respondentes para garantir a saúde das aplicações no ecossistema Fury alinham-se ao framework de SRE do Google (Beyer et al., 2016). A Taxa de Erros foi citada por 18 dos 20 respondentes (90%), a Latência por 17 (85%), o Tráfego por 15 (75%) e a Saturação por 12 (60%). Essas métricas são diretamente correlacionadas aos pilares de SRE de Erros, Latência/Duration, Tráfego/Rate e Saturação, respectivamente. A alta frequência de menção dessas métricas pelos profissionais reforça a importância de um monitoramento contínuo e abrangente para a manutenção da alta disponibilidade e para a rápida detecção e resolução de incidentes no ambiente de microsserviços do Mercado Livre.

Discussão integrada dos achados

Os achados desta pesquisa estabelecem um diálogo produtivo entre a teoria e a prática da engenharia de software. A confirmação de que os padrões de resiliência descritos na literatura, como circuit breaker, retry, bulkheads e rate limiting, estão presentes e são ativamente utilizados na plataforma Fury, percebidos espontaneamente pelos profissionais, valida a premissa teórica de que esses padrões são suficientemente maduros para serem incorporados em plataformas de produção de grande escala. A nota média de 4,6 na avaliação comparativa da facilidade de implementação da alta disponibilidade no Fury, em contraste com a construção do zero, corrobora a tese de Skelton e Pais (2019) sobre a redução da carga cognitiva como um benefício primordial das plataformas de habilitação, permitindo que os desenvolvedores se concentrem na lógica de negócio em vez de na complexidade da infraestrutura.

O principal ponto de tensão identificado, a insuficiência parcial da observabilidade nativa, é consistente com o que Majors, Fong-Jones e Miranda (2022) denominam o problema do observador. Em sistemas altamente distribuídos, a observabilidade baseada em métricas e logs tradicionais é necessária, mas não suficiente; é preciso complementar com rastreamento distribuído e continuous profiling para obter visibilidade real sobre a causalidade dos incidentes. O próprio Mercado Livre publicou recentemente trabalhos sobre continuous profiling utilizando flamegraphs, indicando que essa lacuna está sendo ativamente endereçada (Mercado Libre Tech, 2025), o que demonstra o reconhecimento interno da necessidade de aprimoramento nessa área para garantir um diagnóstico mais eficaz e rápido de problemas em produção.

A curva de aprendizado identificada como um desafio técnico revela um trade-off intrínseco entre a abstração e a autonomia diagnóstica. Forsgren, Humble e Kim (2018) descrevem esse fenômeno como um dos riscos das abstrações de alta ordem: ao eliminar a necessidade de conhecimento técnico profundo no cotidiano, as plataformas podem criar uma dependência que se torna crítica nos momentos de maior pressão, como durante incidentes. Uma resposta possível a esse desafio reside em programas estruturados de imersão técnica, como game days e exercícios de chaos engineering, que expõem periodicamente os desenvolvedores às camadas de infraestrutura que normalmente não veem. Os depoimentos de profissionais com mais de três anos de experiência na plataforma demonstram uma compreensão significativamente mais rica dos mecanismos de alta disponibilidade, sugerindo que o tempo de exposição reduz gradativamente esse déficit diagnóstico, promovendo uma maior capacidade de resolução de problemas complexos.

Do ponto de vista das disciplinas do MBA em Engenharia de Software da USP/ESALQ, o caso do Fury oferece exemplos concretos da aplicação de grande parte do currículo do programa. A arquitetura limpa (Clean Architecture) e o Domain Driven Design (DDD) influenciam o design dos microsserviços, enquanto DevOps e Kubernetes são o substrato técnico do Fury. A observabilidade e o monitoramento sustentam a alta disponibilidade no dia a dia, e a infraestrutura como código torna o provisionamento automático de scopes possível. A integração dessas disciplinas em torno de um caso concreto demonstra como os conhecimentos adquiridos no programa se articulam em um dos casos mais sofisticados de engenharia de plataforma no continente, validando a relevância prática e acadêmica do estudo.

Em síntese, a plataforma Fury do Mercado Livre demonstra ser um modelo exemplar de Internal Developer Platform, combinando práticas de DevOps, arquitetura de microsserviços e estratégia multicloud para alcançar alta disponibilidade em uma escala operacional complexa. Os resultados da pesquisa confirmam a eficácia da abstração de infraestrutura e da automação de pipelines na redução da carga cognitiva dos desenvolvedores, enquanto a identificação de lacunas na observabilidade nativa aponta para áreas de melhoria contínua. Essa visão sistêmica da disponibilidade, que integra resiliência em infraestrutura, deploy e aplicação, é uma contribuição relevante para a literatura sobre IDPs, respondendo à questão central da pesquisa sobre como uma plataforma interna de desenvolvimento consegue garantir alta disponibilidade em escala de dezenas de milhares de microsserviços, mantendo a produtividade de milhares de engenheiros.

4. Conclusão

Este estudo investigou como a plataforma interna de desenvolvimento Fury, do Mercado Livre, garante alta disponibilidade em um ecossistema de dezenas de milhares de microsserviços, ao mesmo tempo em que sustenta a produtividade de seus engenheiros. Verificou-se que a plataforma reduziu significativamente a carga cognitiva dos times de desenvolvimento, por meio da abstração de camadas de infraestrutura, da automação de pipelines de integração e entrega contínuas, e da oferta de estratégias de deploy como blue-green com rollback imediato. Os padrões de resiliência, como circuit breaker, retry com backoff exponencial, bulkheads e rate limiting, foram identificados como primitivas nativas e eficazes, com os profissionais avaliando a facilidade de implementação de alta disponibilidade no Fury com uma média de 4,6 em uma escala de 1 a 5. Contudo, a observabilidade nativa foi percebida como apenas parcialmente suficiente pela maioria dos respondentes, apontando para a necessidade de aprimoramento no diagnóstico de incidentes em ambientes distribuídos. A principal contribuição deste trabalho reside em demonstrar que o modelo de Internal Developer Platform adotado pelo Mercado Livre é um exemplo prático e robusto de como as práticas de DevOps, microsserviços e multicloud podem ser integradas para sustentar uma disponibilidade elevada em cenários de alta complexidade operacional, oferecendo uma visão sistêmica da resiliência que enriquece a literatura sobre IDPs.

Apesar dos achados relevantes, o estudo possui limitações inerentes ao seu desenho metodológico. O levantamento de campo, realizado com 20 profissionais, restringe a generalização estatística dos resultados. Adicionalmente, a dependência de publicações técnicas da própria empresa pode introduzir um viés de seleção positiva na análise. Para estudos futuros, sugere-se a realização de análises comparativas entre o Fury e outras Internal Developer Platforms, como Backstage e Cortex, a fim de identificar melhores práticas e pontos de divergência. Recomenda-se também uma investigação quantitativa do impacto das estratégias de deploy sobre métricas DORA, como lead time e frequência de deploy, e a exploração do potencial da inteligência artificial generativa na automação de padrões de resiliência em plataformas internas de desenvolvimento, visando otimizar ainda mais a manutenção da alta disponibilidade.

Referências Bibliográficas

Amazon Web Services. 2023. Exponential Backoff and Jitter. AWS Architecture Blog. Disponível em: https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/. Acesso em: 10 fev. 2026.

Bardin, L. 2016. Análise de conteúdo. Edições 70, São Paulo, SP, Brasil.

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

Brasil. 2016. Conselho Nacional de Saúde [CNS]. Resolução CNS nº 510. Normas aplicáveis a pesquisas em Ciências Humanas e Sociais. Disponível em: https://conselho.saude.gov.br. Acesso em: 22 fev. 2026.

Brewer, E. A. 2000. Towards robust distributed systems. In: Annual ACM Symposium on Principles of Distributed Computing, 19., Portland. Anais… ACM, New York, NY, USA.

Carvalho, R. F. 2024. Sim, 30 mil deploys por dia. E não, não é no Vale do Silício. LinkedIn. Disponível em: https://linkedin.com. Acesso em: 10 mar. 2026.

Forsgren,

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