Conta digital do Mercado Pago: reservas TCC e saída do relacional

01 · CONTEXTO

Reservar antes de mover o dinheiro

O Mercado Pago é o braço fintech do Mercado Libre e aceita, entre vários meios de pagamento, o dinheiro em conta: valores que a pessoa guarda na carteira digital.

Sempre que alguém paga com dinheiro em conta, garantir que o saldo existe é crucial. Para isso, de forma segura num ambiente naturalmente concorrente, o caminho crítico desses fluxos usa o protocolo TCC (Try-Confirm/Cancel).

O fluxo tem três momentos. Na criação da reserva, um valor é separado para a transação, e se essa etapa falha a transação é abortada na hora. Com a chamada de reserva bem-sucedida, a pessoa recebe a confirmação no aparelho, mas a operação ainda não terminou. Mais tarde, outro microsserviço libera a reserva, debita a conta de origem e transfere o valor ao destinatário na mesma transação de banco de dados, criando movimentos de partida dobrada entre as contas envolvidas.

1. A API de reservas separa o valor da transação; se essa etapa falha, a transação é abortada na hora.

2. Com a chamada de reserva bem-sucedida, a pessoa recebe a confirmação no aparelho, mas a operação ainda não terminou.

3. Mais tarde, outro microsserviço libera a reserva, debita a origem e transfere ao destinatário na mesma transação de banco, criando movimentos de partida dobrada.

4. O banco relacional sustenta esses fluxos e outros serviços críticos.

02 · O PROBLEMA

A tabela que não parava de crescer

O crescimento do Mercado Pago trouxe desafios sobretudo na interação com o banco relacional, que sustenta esses e outros serviços críticos. A tabela de movimentos, onde ficam os movimentos de partida dobrada, cresceu cerca de oito vezes em quatro anos: de aproximadamente 12 TB em 2021 para cerca de 100 TB até o fim de 2024, acrescentando perto de 700 milhões de linhas por dia, segundo o artigo.

O limite chegou a ser concreto: faltavam poucos dias para atingir um limite rígido do banco, porque o tablespace dessa tabela estava perto do número máximo de datafiles permitido. Para escapar, o time migrou com urgência para uma tabela particionada, sem que os usuários percebessem a transição.

Havia também um problema de concorrência. Para preservar a integridade dos dados, o banco relacional usa bloqueio pessimista, que serializa as transações para evitar problemas como a atualização perdida. É eficaz, mas pode degradar o desempenho sob carga pesada e ainda exige estratégias adicionais para lidar com usuários quentes, o que complica a escalabilidade.

03 · BENCHMARK

Escolher o banco medindo

O time montou um benchmark para simular a carga dos serviços principais, com cenários de leitura intensa, de escrita intensa e mistos. Comparou um banco NoSQL conhecido e duas opções NewSQL mais novas contra o relacional atual, migrando dados de produção anonimizados para cada banco. A escolha do tipo de armazenamento é o tema de seleção de banco de dados.

O NoSQL foi escolhido pelo desempenho, pela presença de mercado e pela experiência do time. Sem bloqueio explícito, o time adotou o controle de concorrência otimista, que deu resultados satisfatórios. O relacional atual superou todos os candidatos nos benchmarks, e a necessidade declarada era de estratégias de escalabilidade horizontal.

04 · MIGRAÇÃO

Duas fases e dois bancos em paralelo

A migração foi dividida em duas fases. Na primeira, o serviço de criação de reservas passou para o novo armazenamento. O time queria ganhar resiliência contra degradações do banco relacional e testar a viabilidade do NoSQL com tráfego real de produção. Na fase final, os demais serviços migrariam para a mesma tecnologia.

O objetivo da primeira fase era desacoplar as operações de dinheiro em conta do banco relacional. Para isso foi criado um novo serviço de reservas, que opera exclusivamente sobre o NoSQL. O desafio central passou a ser manter a consistência entre os dois armazenamentos, já que a informação da conta ficaria distribuída entre os dois.

1. Na primeira fase, só a criação de reservas muda de lugar: um novo serviço opera exclusivamente sobre o NoSQL.

2. Os demais serviços ficam para a fase final; até lá, a informação da conta fica distribuída entre os dois bancos.

3. O CDC de cada banco captura as mudanças e as repassa ao outro, nos dois sentidos.

4. Cada serviço também dispara uma sincronização assíncrona de melhor esforço para atualizar saldos, e uma segunda chamada cobre reservas ainda ausentes do relacional.

Para acompanhar a saúde do novo serviço, o time construiu um subsistema de auditoria voltado a dar rastreabilidade completa de cada ação em cada conta e reserva. Ele grava registros de evento com as informações de cada chamada de API, incluindo os estados anterior e posterior da entidade nos dois bancos, erros e dados HTTP.

05 · CONTA QUENTE

Blindar a conta contra o throttling

O time testou a concorrência aumentando gradualmente o volume de pagamentos sobre uma única conta de origem, medindo o desempenho a 1, 5, 10, 20 e 30 transações por segundo, por três minutos em cada patamar. A contenção não melhorou de forma significativa quando os estímulos de sincronização foram sendo desligados, o que mostrou a necessidade de uma estratégia de sincronização eficiente.

Surgiu ainda um limite operacional do motor NoSQL: a vazão de escrita e o tamanho dos itens gravados governam o consumo de recursos. Uma vazão de 30 TPS, com itens de conta guardando centenas de ponteiros para reservas ainda não replicadas ao relacional, bastou para gerar erros de throttling por chave quente.

1. Com vazão alta sobre uma conta e itens de conta carregando centenas de ponteiros para reservas não replicadas, o NoSQL passou a devolver erros de throttling por chave quente.

2. Na etapa preventiva, ao detectar uma conta com ao menos 500 reservas ainda não replicadas ao relacional, o serviço dispara uma sincronização de melhor esforço.

3. Na etapa reativa, ao ocorrer um erro de throttling, a conta é bloqueada temporariamente e a criação de novas reservas é pausada.

4. O objetivo é esvaziar o item da conta de imediato para que as reservas daquela conta possam ser retomadas com segurança.

Nos testes de estresse refeitos, o time relata uma melhora de cerca de 8% a 12% no total de reservas geradas em cada patamar de TPS.

06 · CUSTOS E PRÓXIMOS PASSOS

O preço pago e o que falta

Em desempenho, o novo serviço teve um aumento aproximado de 33% no tempo médio de resposta. Em troca, o time diz ter obtido estabilidade e previsibilidade bem maiores nos percentis do tempo de resposta, algo essencial para um serviço financeiro crítico. O artigo reconhece ainda que o serviço está aberto a otimizações.

O trabalho não terminou. Será preciso refazer por completo o modelo de dados, por causa da passagem do relacional para o não relacional, e desembaraçar trechos da lógica de negócio que, ao longo dos anos, passaram a depender de particularidades do banco relacional.