Em sistemas financeiros de alta escala, a consistência de dados não é negociável, mas a performance frequentemente se torna o maior gargalo. O Uber enfrentou um desafio crítico em sua infraestrutura de contabilidade devido às chamadas hot accounts, onde milhares de atualizações tentavam atingir a mesma conta simultaneamente.
O resultado era a contenção de escrita severa, latência elevada e riscos constantes de falhas no processamento de livros-razão (ledger).
Para solucionar esse impasse, a equipe de engenharia implementou uma estratégia de batching, agrupando operações em janelas de 250 milissegundos.
Essa mudança permitiu que a empresa elevasse a capacidade para mais de 30 atualizações por segundo por conta, reduzindo o tempo de processamento de horas para meros minutos.
O problema das Hot Accounts e a contenção de escrita
O modelo tradicional de contabilidade de dupla entrada exige que cada transação seja validada e persistida individualmente.
Quando a carga de trabalho não é uniforme, algumas contas processam um volume massivo de requisições em curtíssimo intervalo.
Para desenvolvedores brasileiros, isso soa familiar: é o cenário clássico de locks em banco de dados que travam a aplicação e impedem a escalabilidade horizontal.
A abordagem antiga, de uma requisição para uma escrita, criava uma amplificação insustentável.
O custo de coordenação entre leitura, validação e persistência tornava o sistema lento, expondo limitações na arquitetura que impediam o crescimento necessário para suportar o ecossistema global do Uber.
A solução técnica: Batching de 250ms
A solução do Uber consistiu em reestruturar o fluxo de execução para processar múltiplas operações de forma atômica.
O sistema, coordenado via Redis, funciona em três etapas fundamentais:
Agrupamento por afinidade: As atualizações de uma mesma conta recebem uma janela temporal de 250ms. Em vez de dez escritas isoladas, o sistema forma um lote único.
Execução atômica: O lote é processado como uma unidade. A validação e o cálculo do novo saldo ocorrem uma única vez por lote, eliminando a contenção de locks excessivos.
Persistência e propagação: Após o processamento, os resultados são propagados para logs de auditoria e sistemas de downstream, garantindo rastreabilidade total sem comprometer a performance.
| Abordagem | Latência | Throughput | Carga no Banco |
|---|---|---|---|
| Per-request (Antigo) | Baixa (Individual) | Baixo (Bloqueios) | Altíssima |
| Batching (Novo) | Média (Espera 250ms) | Altíssimo | Baixa (Consolidada) |
Arraste para o lado para ver toda a tabela.
Lições para arquitetura de sistemas distribuídos
A escolha da janela de 250ms não foi aleatória; ela representa o equilíbrio entre latência do usuário e eficiência do sistema.
Para arquitetos de software e desenvolvedores no Brasil, a lição principal é que, em Big Tech, a otimização semântica do fluxo de dados supera a simples adição de hardware.
Além disso, o uso de optimistic atomic updates permite que o sistema assuma o sucesso da operação, tratando conflitos apenas em casos excepcionais.
Esse padrão, aplicado corretamente, é o que permite a sistemas financeiros sobreviverem a picos de tráfego, como uma Black Friday, sem entrar em colapso.
Perguntas Frequentes
O que são hot accounts?
São contas que recebem um volume desproporcional de requisições em pouco tempo, gerando contenção de escrita e travamento no banco de dados.
Por que o batching é mais eficiente?
Ele reduz a quantidade de chamadas individuais ao banco de dados e minimiza o overhead de coordenação, processando múltiplas transações dentro de um único ciclo atômico.
Quais os riscos do batching?
O maior risco é o efeito cascata em caso de falhas. Por isso, a implementação exige isolamento de erros ao nível da operação para evitar retentativas massivas (retry amplification).
