A Agoda migrou o cache de preços de hotéis (o chamado tier-one Price Cache) de um deployment com 72 shards de Microsoft SQL↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data → Server para o DragonflyDB, um datastore em memória compatível com Redis. Segundo a reportagem da InfoQ, o cache guarda cerca de 1,5 TB de dados voláteis de preço e absorve aproximadamente 300 mil leituras e 1,5 milhão de escritas por segundo. Depois da troca, a empresa reportou melhora de cerca de 8x na latência P99 de leitura, com o DragonflyDB servindo em torno de 300 mil requisições por segundo a aproximadamente 8 ms de P99.
Para quem constrói software no Brasil, o caso interessa menos pelo nome do produto e mais pela sequência de decisões: como sair de um cache relacional shardado sem parar produção, como validar paridade de dados antes de virar tráfego e como fazer failover sem coordenador central. Nada disso depende de estar no volume da Agoda; é engenharia aplicável a qualquer serviço de leitura pesada com dados que expiram.
O gargalo que o SQL Server virou
A arquitetura anterior exigia roteamento de shard no nível da aplicação entre os 72 shards de SQL Server. Escalar significava aumentos de hardware em incrementos predefinidos, além de remapeamento manual de shards e migração de dados. A Agoda dobrou a capacidade de hardware no início de 2024 e, mesmo assim, estava se aproximando dos limites de novo em menos de um ano. Havia ainda um processo separado só para limpar dados de fornecedores expirados.
O diagnóstico do engenheiro-líder Clarkson Chang é o ponto em que muita equipe brasileira vai se reconhecer:
Ficou claro que continuar adicionando recursos ao SQL Server não era uma estratégia viável ou de bom custo-benefício no longo prazo.
Clarkson Chang, engenheiro-líder da Agoda
A leitura prática aqui: usar um banco relacional como cache de altíssima taxa de escrita cobra um preço em rigidez operacional. Cada expansão vira projeto, e o custo por unidade de throughput cresce. Quando o padrão de acesso é essencialmente chave-valor com expiração, um datastore em memória tende a encaixar melhor no formato do problema.
Por que DragonflyDB e não só Redis
A Agoda não confiou apenas em benchmarks publicados: avaliou o DragonflyDB contra a própria carga. A arquitetura shared-nothing e multithread, a compatibilidade com Redis, a escala baseada em cluster e a expiração de chaves nativa casaram com um workload que depende fortemente de MGET e SET.
Para reproduzir produção antes de tocar em produção, a equipe usou o memtier_benchmark recriando a proporção real de 1 leitura para 6 escritas e operações MGET com média de 10 chaves. Esse é o detalhe que separa teste sério de teste de marketing: em vez de rodar o benchmark padrão da ferramenta, modelaram o ratio e o tamanho de operação do serviço real.
| Métrica | Antes (72 shards SQL Server) | Depois (DragonflyDB) |
|---|---|---|
| Dado em cache | ~1,5 TB volátil | ~1,5 TB volátil |
| Leituras/s | ~300 mil | ~300 mil a ~8 ms P99 |
| Escritas/s | ~1,5 milhão | ~1,6 milhão a ~10 ms P99 |
| Latência P99 leitura | linha de base | ~8x menor |
| Modelo de escala | incrementos de hardware + remap manual de shard | cluster, 3 shards por cluster |
A migração foi incremental, e é aí que está a lição
O ponto mais reaproveitável do caso não é o número de latência, é o método de virada sem downtime. A Agoda começou com uma instância de 1 TB só para dados quentes, mas o crescimento orgânico empurrou o dataset perto do limiar de segurança de 90% de memória. A resposta foi um desenho com três shards por cluster, expandido para segurar o 1,5 TB completo, chegando a ~1,6 milhão de escritas/s a ~10 ms P99.
Antes de mover clientes, veio a etapa de dual reads: o SQL Server continuava servindo as requisições enquanto a Price API buscava o dado correspondente no DragonflyDB de forma assíncrona. Em vez de comparar o payload de preço inteiro (caro e frágil), a equipe checou duas dimensões baratas:
- contagem de fornecedores (
supplier counts); - comprimento dos dados de preço (
price-data lengths).
Os resultados eram emitidos como métricas Prometheus. As duas dimensões alcançaram mais de 99,9% de paridade antes de qualquer tráfego real ser desviado. Só então a Agoda usou um experimento A/B para mover clientes gradualmente; depois de algumas semanas, 100% do tráfego estava no DragonflyDB e os caminhos de leitura e escrita do SQL Server foram aposentados.
Esse roteiro (shadow read barato, métrica de paridade, A/B de tráfego, desligamento do legado) é replicável em qualquer troca de datastore. A escolha de comparar proxies de integridade em vez do objeto inteiro é o tipo de decisão que evita gastar tempo comparando bytes que não importam.
Failover sem coordenador central
A mudança final atacou o tratamento de falhas. Dois clusters DragonflyDB, A e B, dão alta disponibilidade. Em vez de um coordenador central decidindo quem está saudável, cada pod da aplicação compara de forma independente o cache-hit ratio dos dois clusters usando cinco minutos de observações locais.
A regra é estatística e simétrica:
- uma divergência significativa de 10 pontos percentuais marca um cluster como não legível;
- a recuperação exige que a diferença caia para dentro de 3 pontos percentuais.
Numa simulação de outage, cerca de 40 pods detectaram a falha e entraram em failover em aproximadamente dois minutos, sem intervenção manual. O desenho descentralizado evita o clássico ponto único de falha do coordenador e remove a dependência de alguém apertar botão às 3 da manhã.
O que fica em aberto
A Agoda acoplou a troca de datastore a checagens de paridade em produção, migração controlada de tráfego, comportamento explícito de cache warming e detecção descentralizada de falha. O ganho não foi só latência menor: foi um modelo de escala menos rígido e menos manutenção operacional em torno de dado velho e failover.
O material não abre números de custo absoluto nem o hardware exato por trás dos clusters, então a comparação de TCO fica na afirmação qualitativa de Chang. Também vale lembrar o óbvio para quem for copiar a receita: um cache em memória de 1,5 TB tem seu próprio custo de RAM e o limiar de 90% mostra que a margem de memória vira uma variável de operação constante. Para serviços brasileiros de leitura pesada com dados que expiram (preço, disponibilidade, feed, sessão), o valor aqui é o roteiro de migração e a arquitetura de failover, mais do que a marca do datastore.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Baeta. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
Comentários
Ninguém comentou ainda. Começa a conversa?