Grab e Aerospike: a migração ganhou no modelo de acesso, não só no banco

A Grab migrou seu Counter Service para Aerospike e relata queda de aproximadamente 50% na latência p99 de leitura, redução de disco de cerca de 3 TB para 1 TB e custo por nó entre 45% e 50% menor.[16] O serviço participa da plataforma antifraude e atende aproximadamente um bilhão de requisições por dia.[16] Os ganhos pertencem a esse serviço e ao redesenho feito, não a uma comparação universal entre bancos.

O que muda para quem desenvolve

Antes da mudança, a equipe isolou o acesso a dados da lógica de negócio em Rust, usando uma fachada com implementações antiga, nova e simulada.[16] As leituras em sombra cresceram de 5% para 20%, 50% e 100%, com comparação de resultados antes da transferência do tráfego efetivo.[16]

Minha análise é que a abstração teve uma função concreta: permitir comparar comportamento sem trocar toda a lógica de uma vez. Esse tipo de fronteira é mais útil que uma camada genérica criada apenas para esconder o nome do banco.

O redesenho consolidou intervalos de contador e granularidade em registros com mapas ordenados por timestamp, usando operações atômicas de incremento e remoção explícita de entradas antigas.[16] A filtragem de intervalos passou em parte para a aplicação, que recebe os mapas.[16] Portanto, a otimização também moveu responsabilidade entre armazenamento e serviço.

Como aplicar

Para migrar contadores de uso ou limites de API, comece especificando a semântica: quais eventos contam, como o intervalo é delimitado e quando dados antigos deixam de participar da consulta. Sem isso, comparar duas respostas pode esconder uma divergência de regra.

Proponho validar primeiro com reprodução de eventos em ambientes isolados. Inclua incrementos concorrentes, consultas nas fronteiras de intervalo e remoção de dados antigos. Compare tanto os valores finais quanto o comportamento durante atualizações.

Depois, se houver condições operacionais, use leituras em sombra com impacto controlado. Registre equivalência, latência de cauda, volume retornado e custo adicional da comparação. O sistema antigo continua sendo referência provisória, mas divergências devem ser investigadas: ele também pode carregar erros.

Defina um limite de tamanho dos mapas e meça o custo de filtragem no cliente. Não considere apenas espaço em disco. Uma consolidação que reduz registros precisa continuar cabendo nos limites de leitura, memória e manutenção do serviço.

Por fim, documente quando aumentar tráfego e quando interromper. Um resultado agregado bom não deve ocultar uma categoria de consultas com respostas diferentes.

Cuidados e limites

A migração encontrou problemas no cliente Rust inicialmente síncrono e no tratamento de DNS durante substituição de cluster; a equipe trabalhou com mantenedores antes de avançar.[16] Segundo a Grab, a conclusão ocorreu sem indisponibilidade nem problemas de integridade.[16]

Esse resultado não garante uma migração equivalente em outro produto. Também não se deve transformar redução por nó em redução igual da conta inteira. A lição é testar contrato, formato dos dados e caminho de acesso em conjunto. Trocar a marca do banco sem revisar essas partes pode preservar justamente os custos que motivaram a mudança.

Fonte

[16] Fonte: InfoQ