KVS: key-value como produto de plataforma (642 milhões de operações por minuto)

01 · CONTEXTO

A carteira digital do Mercado Pago

O Mercado Pago, braço fintech do Mercado Libre, é um ecossistema de milhares de microsserviços que processam transações financeiras. Um dos meios de pagamento é o dinheiro em conta, valor que o usuário guarda na carteira digital.

Antes de debitar, o sistema precisa garantir que há saldo, num ambiente naturalmente concorrente. Por isso o caminho crítico desses fluxos implementa o protocolo TCC (Try-Confirm/Cancel), com a reserva do valor num primeiro passo e a transferência num passo posterior.

1. O fluxo começa na criação da reserva: um valor é separado para a transação e, se esse passo falha, a transação é abortada de imediato.

2. Com a reserva criada, o usuário recebe a confirmação no dispositivo, mas a operação ainda não terminou.

3. Mais tarde, outro microsserviço libera a reserva, debita a conta de origem e credita o destinatário na mesma transação de banco.

O banco relacional da empresa dá suporte a esses e a outros serviços críticos.

02 · O PROBLEMA

Quando o banco único vira o gargalo

Com cargas cada vez mais pesadas, o banco relacional virou obstáculo à escalabilidade horizontal da carteira. A tabela de movimentos, que guarda os lançamentos de partida dobrada, cresceu oito vezes em quatro anos.

O crescimento foi de cerca de 12 TB em 2021 para cerca de 100 TB no fim de 2024, com quase 700 milhões de linhas novas por dia. A equipe chegou a ficar a poucos dias de um limite rígido: o tablespace da tabela estava prestes a atingir o número máximo de datafiles, e a situação foi evitada com uma migração urgente para uma tabela particionada.

03 · BENCHMARK

Como escolher o novo banco

A equipe avaliou três candidatos em um benchmark que simulava as cargas dos serviços-chave: um banco NoSQL conhecido e duas opções NewSQL mais novas.

A decisão recaiu sobre o NoSQL, pelo desempenho, pela presença no mercado e pela experiência da equipe, apoiando-se em controle de concorrência otimista por falta de bloqueio explícito.

04 · MIGRAÇÃO

Duas fases e dois bancos sincronizados

O plano foi dividido em duas fases. Por ser um serviço hipercrítico, a migração foi feita por etapas. Na primeira, o serviço de criação de reservas foi movido para o novo armazenamento, com o objetivo de aumentar a resiliência a degradações do banco relacional. Na fase final, os demais serviços seriam migrados.

O novo serviço de reservas opera exclusivamente sobre o NoSQL. O desafio passou a ser manter a consistência entre dois armazenamentos, já que a informação de conta ficaria distribuída entre ambos.

Para sincronizar, usaram captura de mudanças (CDC) nos dois bancos, nos dois sentidos. Somaram duas chamadas de API de sincronização: uma assíncrona, de melhor esforço, disparada por cada serviço para atualizar saldos, e outra para quando um serviço precisa de reservas que não estão no relacional.

Com recursos da plataforma Fury, a equipe criou um subsistema de auditoria que grava registros de evento para cada chamada de API, com os estados anterior e posterior da entidade nos dois bancos, erros e dados HTTP. A Fury também foi usada nos testes de estresse.

1. Na primeira fase, o novo serviço de reservas passa a operar exclusivamente sobre o banco NoSQL.

2. Para manter os dois bancos consistentes, a captura de mudanças corre nos dois sentidos: o que muda em um é repassado ao outro.

3. Os demais serviços só migram na fase final; para quando um serviço precisa de reservas que não estão no relacional, existe uma chamada de sincronização que garante o dado de imediato.

4. No teste de estresse, 30 TPS sobre uma conta, com itens guardando centenas de ponteiros para reservas ainda não replicadas, bastaram para gerar erros de limitação por chave quente.

5. Etapa preventiva: ao detectar uma conta com ao menos 500 reservas ainda não replicadas ao relacional, o sistema dispara uma sincronização de melhor esforço.

6. Etapa reativa: ao atingir um erro de limitação, a conta é bloqueada temporariamente e a criação de novas reservas pausa, para drenar o item e retomar com segurança.

05 · RESULTADOS

O que o teste de estresse mostrou

O teste elevou o volume de pagamentos sobre uma única conta de origem em patamares de 1, 5, 10, 20 e 30 TPS, por três minutos cada. A contenção não melhorou muito quando os estímulos de sincronização foram desligados aos poucos, o que mostrou a necessidade de uma estratégia eficiente de sincronização.

Nos testes revisados, houve melhora de cerca de 8% a 12% no total de reservas geradas em cada patamar de TPS. Em contrapartida, o novo serviço teve aumento aproximado de 33% no tempo médio de resposta.

Segundo o texto, essa troca trouxe estabilidade e previsibilidade bem maiores nos percentis do tempo de resposta, algo essencial para um serviço financeiro crítico. Falta ainda refazer por completo o modelo de dados ao sair do relacional.