Mercado Envios: do MySQL único para a América Latina a células

01 · CONTEXTO

Um banco só para a região inteira

O sistema de estoque do Mercado Envíos, do Mercado Libre, rodava sobre o que a empresa descreve como a segunda maior instância MySQL da casa. Toda entrada, saída, reserva e movimentação logística dependia de um único banco que não conseguia mais escalar.

A arquitetura inicial era simples: vários serviços de estoque ligados a um único cluster MySQL. Esse cluster cuidava da disponibilidade de estoque por centro de fulfillment, das reservas para envios de fulfillment e das movimentações logísticas entre armazéns, vendedores e destinos.

1. Os clientes da API chamam os serviços de estoque.

2. Todos os serviços de estoque convergem para um único cluster MySQL.

3. Com esse desenho, uma única falha podia afetar operações em vários países da região.

Segundo o post, a latência de operações críticas vinha subindo, e a pergunta passou a ser o que fazer quando escalar na vertical deixa de ser opção.

02 · POR QUE CÉLULAS

Sem flavor maior e sem microsserviços por reflexo

Por anos a escala vertical resolveu os problemas; no fim, não havia mais flavors maiores disponíveis e depender de uma única instância MySQL virou risco sistêmico.

Em vez de dividir tudo em microsserviços, a equipe pesou que multiplicar saltos de rede ou pontos de falha tornaria mais difíceis exigências do domínio como latência extremamente baixa mesmo sob pico e forte consistência de estoque. Por isso mantiveram um monólito intencional no núcleo do sistema.

03 · A ARQUITETURA

Células por grupo de países, escrita separada de leitura

A arquitetura em células é conceitualmente parecida com as divisórias estanques de um navio: cada célula opera de forma autônoma, com computação, banco e tráfego próprios. Se uma célula falha, as demais continuam atendendo requisições. Esse isolamento reduz o raio de impacto.

O modelo introduziu duas camadas de segregação. Na primeira, os países foram agrupados em três células. Na segunda, os fluxos foram divididos: escritas estritamente consistentes e críticas para o negócio de um lado, leituras mais flexíveis, apoiadas em réplicas e cache, de outro.

1. Os clientes chegam a uma camada de tráfego que fica na frente das células.

2. A camada de tráfego é ligada ao serviço de cada célula.

3. Cada célula tem serviço e banco próprios.

4. Se uma célula falhar, as demais continuam atendendo requisições.

Implementar células é também um desafio operacional. A Fury, plataforma interna de desenvolvimento do Mercado Libre, permitiu criar serviços e bancos de cada célula com padrões consistentes e operar pipelines de deploy independentes por célula.

04 · ROTEAMENTO

Quando a API não tem chave de célula

Ao desenhar o roteamento, a equipe viu que várias APIs não tinham uma chave natural que identificasse a qual célula a entidade pertencia. Criar um atributo novo quebraria a compatibilidade com clientes existentes e exigiria coordenar mudanças com dezenas de equipes e serviços.

A saída foi usar duas estratégias. Para entidades legadas, um fallback de roteamento retrocompatível; para dados novos, uma estratégia determinística de IDs.

1. O cliente faz a mesma requisição de sempre, sem mudanças.

2. A camada de tráfego encaminha a requisição a todas as células.

3. A célula que guarda a entidade responde.

4. Se todas as células devolvem 404, o recurso realmente não existe.

05 · IDS COMO CHAVE

Faixas de ID por célula

O broadcast resolveu o problema dos registros legados, mas as entidades novas pediam roteamento determinístico. Os IDs atrapalhavam: eram públicos e parte de contratos de API antigos, eram sequenciais e gerados por uma única instância MySQL, e não tinham significado embutido. Isso trazia o risco de colisão de IDs entre células se dois primários gerassem números sobrepostos.

A solução foi dar a cada célula uma faixa exclusiva de IDs. Uma entidade nova criada numa célula recebe um ID que nunca colide com o de outra célula, os IDs mantêm o formato original e o próprio ID passa a ser a chave de roteamento.

06 · MIGRAÇÃO E RESULTADO

Migrar dezenas de terabytes sem parar a logística

A equipe migrou dezenas de terabytes para três células independentes. A leitura continuou sem interrupção e as escritas foram pausadas só numa janela breve e controlada. O roteiro de cada janela era copiar o banco para a célula de destino, pausar as escritas por pouco tempo e manter as leituras no banco original.

Como a maioria dos fluxos é assíncrona, a pausa curta de escrita teve impacto mínimo nos clientes finais. Depois que a célula recebia seus dados, ela entrava no ar aos poucos: primeiro ligaram as leituras e validaram fluxos críticos, depois liberaram as escritas, protegidas contra contaminação entre células. Após a validação, o tráfego de leitura foi deslocado para a nova célula sem indisponibilidade.

1. As escritas vão ao primário da célula, onde precisam ser estritamente consistentes.

2. As leituras, mais flexíveis, são apoiadas em réplicas e cache.

3. O serviço SQL totalmente gerenciado trouxe replicação com garantias de consistência abaixo de 100 ms.

4. Com as réplicas atendendo leitura, as leituras no primário foram eliminadas.

Um ano após a migração, a latência p95/p99 havia caído cerca de 70%, a degradação recorrente causada pelas janelas de backup foi eliminada e a equipe passou de escalar um banco gigante a escalar só as células que precisam.