30.000 deploys diários: desvendando os segredos do Mercado Livre

Outro dia, em uma das minhas aulas no MBA da Strides, o professor soltou um número que me deixou inquieto: 30.000 deploys por dia no Mercado Livre. Confesso que, mesmo com mais de 20 anos de estrada no desenvolvimento de software, esse número me soou quase como uma heresia. Lembro dos tempos em que um deploy era um evento, um ritual que envolvia planejamento minucioso, janelas de manutenção na madrugada e uma equipe inteira de prontidão para o caso de algo dar errado. Fazer 30.000 deles em um único dia? Parecia ficção científica.

Como um "provocador" por natureza, não pude deixar essa informação passar batida. Fui atrás de entender como o Mercado Livre, uma empresa que nasceu aqui na América Latina e que hoje é um gigante global do e-commerce e da tecnologia financeira, conseguiu atingir esse patamar de agilidade e escala. Foi aí que me deparei com quatro artigos publicados pela própria equipe de tecnologia do Mercado Livre, que, juntos, contam uma história fascinante sobre a evolução de sua infraestrutura e cultura de engenharia.

Decidi, então, mergulhar nesses materiais, complementá-los com outras informações que garimpei na internet e escrever este artigo. Meu objetivo é duplo: primeiro, trazer um resumo mastigado e contextualizado de como funciona a TI do Mercado Livre, para que outros profissionais da área possam se inspirar (e, por que não, se espantar). E segundo, como o velho cético que sou, quero analisar criticamente essa jornada, questionar as escolhas feitas e refletir sobre o que realmente podemos aprender com a experiência deles. Afinal, com 18.000 engenheiros de software no time, será que o modelo do Mercado Livre é uma receita de bolo que qualquer um pode seguir? Ou será que estamos diante de uma realidade tão específica que só serve para nos fazer sonhar?

A obsessão pela velocidade: por que 30.000 deploys?

Antes de entrarmos nos "comos", é fundamental entendermos o "porquê". Por que uma empresa se daria ao trabalho de construir uma máquina de engenharia capaz de fazer 30.000 deploys por dia? A resposta, na minha visão, está na natureza do negócio do Mercado Livre. Eles atuam em um dos mercados mais competitivos e dinâmicos do mundo, onde a capacidade de inovar, experimentar e responder rapidamente às mudanças de comportamento do consumidor não é um diferencial, mas uma questão de sobrevivência.

Cada nova funcionalidade, cada ajuste em um algoritmo de recomendação, cada melhoria na experiência de pagamento pode representar milhões em receita e um passo à frente da concorrência. Nesse cenário, a velocidade com que uma ideia se transforma em código em produção é um dos ativos mais valiosos da empresa. E é aí que os 30.000 deploys diários fazem sentido. Eles não são um fim em si mesmos, mas um meio para um fim: a agilidade do negócio.

Essa busca incessante pela velocidade, no entanto, tem um preço. E é um preço alto, que muitas empresas não estão dispostas ou não têm condições de pagar. Envolve uma mudança profunda não apenas na tecnologia, mas também na cultura, na estrutura organizacional e na forma como as pessoas trabalham. E é essa transformação que vamos dissecar a seguir.

O monólito e a inevitável separação: uma história de amor e ódio

Como a maioria das empresas de tecnologia que nasceram no final dos anos 90, o Mercado Livre começou sua jornada com uma arquitetura monolítica. Um único e gigantesco bloco de código que continha todas as funcionalidades da plataforma. Na época, essa era a abordagem padrão e, para ser justo, ela funcionou muito bem por um bom tempo. O monólito permitiu que a empresa crescesse rapidamente, adicionasse novas funcionalidades e se estabelecesse como líder de mercado.

No entanto, o sucesso trouxe consigo o seu próprio veneno. Com o crescimento exponencial do número de usuários, de transações e, principalmente, de desenvolvedores trabalhando no mesmo código, o monólito começou a mostrar suas rachaduras. O tempo de build e de teste se tornou cada vez maior, a complexidade do código atingiu níveis estratosféricos e o risco de um pequeno erro em uma parte do sistema derrubar a plataforma inteira era uma ameaça constante.

A imagem que me vem à mente é a de um navio que, de tanto ser remendado e expandido, se torna cada vez mais lento, difícil de manobrar e propenso a naufragar a qualquer momento. O Mercado Livre se viu diante de uma encruzilhada: continuar remendando o navio ou construir uma frota de barcos menores, mais ágeis e independentes.

Eles escolheram a segunda opção. A decisão de abandonar o monólito e migrar para uma arquitetura de microsserviços foi um marco na história da empresa. Mas, como qualquer um que já tenha participado de uma migração desse porte sabe, essa é uma jornada longa, árdua e cheia de armadilhas. Não se trata apenas de quebrar o código em pedaços menores, mas de repensar toda a forma como o software é desenvolvido, implantado e operado.

A revolução dos microsserviços e a cultura do "você constrói, você opera"

A adoção dos microsserviços no Mercado Livre foi uma resposta direta aos problemas do monólito. A ideia era simples na teoria, mas complexa na prática: dividir a aplicação em um conjunto de serviços menores, cada um responsável por uma funcionalidade específica do negócio (pagamentos, envios, anúncios, etc.). Cada serviço poderia ser desenvolvido, implantado e escalado de forma independente, por uma equipe dedicada.

Essa abordagem prometia uma série de benefícios: maior agilidade, escalabilidade granular, isolamento de falhas e a possibilidade de usar diferentes tecnologias para diferentes serviços. No entanto, ela também trazia consigo uma nova leva de desafios. Como gerenciar a comunicação entre centenas, ou mesmo milhares, de serviços? Como garantir a consistência dos dados? Como monitorar e depurar um sistema distribuído tão complexo?

É aqui que muitas empresas tropeçam. Elas adotam os microsserviços como uma bala de prata tecnológica, mas se esquecem de que essa arquitetura exige uma mudança cultural profunda. E foi exatamente nesse ponto que, na minha opinião, o Mercado Livre acertou em cheio. Eles entenderam que, para fazer os microsserviços funcionarem, precisavam quebrar os silos entre as equipes de desenvolvimento e de operações.

Nascia assim a cultura do "você constrói, você opera" (you build it, you run it). A ideia de que a equipe que desenvolve um serviço também é responsável por sua operação em produção. Isso significa que os desenvolvedores não podem mais "jogar o código por cima do muro" para a equipe de infraestrutura. Eles precisam se preocupar com a qualidade, a performance, a segurança e a resiliência de seus serviços.

Essa mudança de mentalidade é fundamental para o sucesso de uma arquitetura de microsserviços. Ela cria um senso de propriedade e de responsabilidade que leva a um software de melhor qualidade. Mas, para que isso funcione na prática, é preciso dar aos desenvolvedores as ferramentas e a autonomia necessárias para que eles possam, de fato, operar seus próprios serviços. E é aí que entra em cena o próximo protagonista da nossa história: o Kubernetes.

Domando a complexidade: o papel do Kubernetes

Com milhares de microsserviços rodando em produção, o Mercado Livre se deparou com um novo desafio: como orquestrar tudo isso? Como garantir que os serviços estejam sempre disponíveis, que eles escalem de acordo com a demanda e que os recursos de infraestrutura sejam utilizados de forma eficiente?

A resposta para essa pergunta foi o Kubernetes, a plataforma de orquestração de contêineres de código aberto que se tornou o padrão de fato da indústria. O Kubernetes oferece uma camada de abstração sobre a infraestrutura subjacente, permitindo que os desenvolvedores tratem o data center como um único e gigantesco computador. Com o Kubernetes, eles podem empacotar suas aplicações em contêineres, descrever como elas devem ser executadas e deixar que a plataforma se encarregue do resto.

A adoção do Kubernetes foi um passo crucial na jornada do Mercado Livre. Ele forneceu a base tecnológica para que a empresa pudesse gerenciar sua imensa frota de microsserviços de forma automatizada e escalável. Mas o Kubernetes, por si só, não é uma solução mágica. Ele é uma ferramenta extremamente poderosa, mas também notoriamente complexa. A curva de aprendizado é íngreme e a sua configuração e manutenção exigem um conhecimento profundo de redes, armazenamento, segurança e sistemas distribuídos.

E é aqui que a história do Mercado Livre se torna ainda mais interessante. Em vez de simplesmente adotar o Kubernetes "puro" e deixar que cada equipe se virasse para aprender a usá-lo, eles decidiram construir uma camada de abstração sobre ele. Uma plataforma que escondesse a complexidade do Kubernetes e oferecesse aos desenvolvedores uma experiência de uso mais simples, padronizada e produtiva. Nascia assim a Plataforma Interna de Desenvolvimento (IDP) do Mercado Livre, batizada de Fury.

A arma secreta: a Plataforma Interna de Desenvolvimento (IDP)

Se eu tivesse que apontar um único fator como o principal responsável pelos 30.000 deploys diários do Mercado Livre, seria a sua Plataforma Interna de Desenvolvimento. A Fury é o coração da máquina de engenharia da empresa, a "estrada pavimentada" que guia os desenvolvedores desde a primeira linha de código até a implantação em produção.

Uma IDP, em essência, é um conjunto de ferramentas e serviços integrados que automatizam e simplificam o ciclo de vida do desenvolvimento de software. Ela oferece aos desenvolvedores uma experiência de "autoatendimento", onde eles podem criar novos projetos, provisionar infraestrutura, configurar pipelines de CI/CD, monitorar suas aplicações e muito mais, tudo isso sem a necessidade de abrir um chamado para a equipe de infraestrutura.

A Fury, no caso do Mercado Livre, é uma IDP extremamente sofisticada, construída sobre o Kubernetes e composta por uma série de ferramentas de código aberto e soluções desenvolvidas internamente. Ela inclui, entre outras coisas:

• Um CLI (Command Line Interface) unificado: que permite aos desenvolvedores interagir com a plataforma de forma simples e consistente.
• Templates de aplicação: que aceleram a criação de novos serviços, já com todas as configurações de build, teste, deploy e monitoramento pré-configuradas.
• Um pipeline de CI/CD totalmente automatizado: que garante que cada alteração no código passe por uma série de validações de qualidade e segurança antes de chegar à produção.
• Um service mesh (baseado em Istio): que gerencia a comunicação entre os microsserviços, oferecendo funcionalidades como balanceamento de carga, roteamento inteligente, controle de tráfego e observabilidade.
• Uma plataforma de observabilidade completa: que agrega logs, métricas e traces de todas as aplicações, permitindo que os desenvolvedores identifiquem e resolvam problemas rapidamente.

O resultado de tudo isso é uma redução drástica da carga cognitiva sobre os desenvolvedores. Eles não precisam mais ser especialistas em Kubernetes, em redes, em segurança ou em qualquer outra área da infraestrutura. Eles podem focar naquilo que realmente importa: escrever o código que resolve os problemas do negócio.

A Fury é a materialização da cultura do "você constrói, você opera". Ela dá aos desenvolvedores a autonomia e as ferramentas para que eles possam, de fato, serem donos de seus serviços. E é essa combinação de arquitetura, tecnologia e cultura que permite ao Mercado Livre atingir a incrível marca de 30.000 deploys por dia.

Os perigos da velocidade e o lado sombrio da abstração

Até aqui, a história do Mercado Livre parece um conto de fadas da engenharia de software. Uma empresa que superou os desafios do crescimento, adotou as tecnologias mais modernas e construiu uma máquina de desenvolvimento de fazer inveja a qualquer gigante do Vale do Silício. Mas, como o velho cético que sou, não posso deixar de levantar algumas questões incômodas.

Essa busca incessante pela velocidade não tem um custo humano? Será que um ambiente com 30.000 deploys por dia não gera uma pressão insustentável sobre os desenvolvedores? A cultura do "move fast and break things", popularizada pelo Facebook, pode ser empolgante no início, mas também pode levar ao burnout e a uma sensação constante de que se está sempre correndo atrás do prejuízo.

E a qualidade do software? Como garantir que, com tantas alterações sendo feitas a todo momento, o sistema como um todo permaneça estável e confiável? O Mercado Livre certamente tem mecanismos de controle de qualidade, como testes automatizados, canários e feature flags. Mas, mesmo com tudo isso, o risco de um deploy mal-sucedido causar um impacto significativo no negócio é real. E, em um sistema tão complexo e distribuído, rastrear a causa raiz de um problema pode ser como encontrar uma agulha em um palheiro.

Outra preocupação que tenho é com o excesso de abstração. A Fury, ao esconder a complexidade do Kubernetes e da infraestrutura, pode acabar criando uma geração de desenvolvedores que sabem usar as ferramentas de alto nível, mas não têm a menor ideia do que está acontecendo por baixo dos panos. Isso pode não ser um problema no dia a dia, mas, quando algo realmente sério acontece, quando é preciso mergulhar fundo para resolver um problema complexo, essa falta de conhecimento fundamental pode ser fatal.

E, por fim, há o risco de se criar uma "gaiola de ouro". Uma IDP tão customizada e tão integrada à cultura e aos processos da empresa pode acabar se tornando um obstáculo à inovação no futuro. Se uma nova tecnologia disruptiva surgir, o Mercado Livre terá a agilidade para adotá-la? Ou a sua plataforma, que hoje é a sua maior força, se tornará a sua maior fraqueza?

O que nós, meros mortais, podemos aprender com o Mercado Livre?

É evidente que o modelo do Mercado Livre não é para todos. A maioria das empresas não tem 18.000 engenheiros, não precisa fazer 30.000 deploys por dia e não tem os recursos para construir uma IDP tão sofisticada. Tentar copiar a receita deles sem ter a mesma escala e a mesma cultura é uma fórmula para o desastre.

No entanto, isso não significa que não possamos aprender com a experiência deles. Na minha opinião, as lições mais valiosas que podemos extrair da jornada do Mercado Livre não são sobre as tecnologias específicas que eles usam, mas sobre os princípios que guiam as suas decisões.

• Foco na experiência do desenvolvedor: O Mercado Livre entendeu que, para ter agilidade no negócio, precisava primeiro ter agilidade no desenvolvimento. Eles investiram pesado em ferramentas e processos que removem o atrito do dia a dia dos seus engenheiros e lhes permitem focar naquilo que eles fazem de melhor: criar valor.
• Evolução contínua: A arquitetura e a plataforma do Mercado Livre não nasceram prontas. Elas são o resultado de anos de evolução, de experimentação, de erros e de acertos. Eles não tiveram medo de abandonar o que não funcionava mais e de abraçar novas ideias, sempre com um olhar crítico e pragmático.
• A cultura come a estratégia no café da manhã: A tecnologia é importante, mas a cultura é fundamental. O Mercado Livre não teria chegado onde chegou sem a sua cultura de autonomia, de responsabilidade e de aprendizado contínuo. Eles investiram na formação de seus times, na disseminação do conhecimento e na criação de um ambiente onde as pessoas se sentem seguras para experimentar e para errar.

Conclusão: a busca incessante pelo equilíbrio

A jornada do Mercado Livre aos 30.000 deploys diários é, sem dúvida, uma das histórias mais impressionantes da engenharia de software moderna. Ela é um testemunho do que é possível alcançar quando se combina uma visão de negócio arrojada, uma estratégia de tecnologia bem definida e uma cultura de engenharia de excelência.

Mas, ao final desta análise, a pergunta que fica para mim não é sobre como podemos copiar o modelo deles, mas sobre como podemos adaptar os seus princípios à nossa própria realidade. Como podemos melhorar a experiência dos nossos desenvolvedores? Como podemos criar uma cultura de maior autonomia e responsabilidade? Como podemos usar a tecnologia não como um fim em si mesma, mas como uma alavanca para a inovação e para o crescimento do nosso negócio?

A resposta para essas perguntas não está em um framework, em uma ferramenta ou em um artigo de blog. Ela está na nossa capacidade de questionar o status quo, de experimentar novas abordagens e de encontrar o equilíbrio certo entre a velocidade e a qualidade, entre a abstração e o conhecimento fundamental, entre a autonomia e a governança.

E você, o que pensa sobre tudo isso? Será que a busca pela velocidade a qualquer custo é o caminho certo? Ou será que estamos perdendo algo importante no meio dessa corrida frenética? A discussão está aberta.

Fontes:

Artigo 1, Artigo 2, Artigo 3, Artigo 4, Artigo 5 e Artigo 6.