Como o Airbnb Migrou Seu Grafo de Identidade de 7 Bilhões de Nós para uma Plataforma Interna de Knowledge Graph

Por que um Knowledge Graph é Essencial para Trust & Safety

Toda plataforma grande enfrenta um desafio fundamental: entender como usuários, dispositivos e contas estão conectados. Para o Airbnb, essas conexões são críticas para detectar fraudes, prevenir roubos de conta e aplicar políticas de confiança.

O grafo de identidade do Airbnb é a espinha dorsal desse esforço. Ele modela usuários e seus relacionamentos como vértices e arestas em um banco de dados de grafos, permitindo consultas como:

• “Essa nova conta está ligada a alguma conta previamente banida?”
• “Esse ID de dispositivo aparece em várias reservas suspeitas?”

Com o crescimento da plataforma, o grafo explodiu em complexidade — 7 bilhões de nós, 11 bilhões de arestas, crescendo 5 milhões de arestas por dia. A arquitetura original não aguentava mais. Este case study mostra a evolução, a migração para uma infraestrutura interna de knowledge graph e as otimizações que fizeram a diferença.

As Três Iterações do Grafo de Identidade

Fase 1: Relacional + KV Store

Inicialmente, o Airbnb armazenava dados de usuários em um banco relacional e as listas de arestas como blobs JSON em um key-value store. Conforme a densidade do grafo aumentou, os joins ficaram proibitivamente caros e a abordagem JSON tornou as consultas de travessia lentas e frágeis.

Pontos de dor: Alto custo, baixa escalabilidade, sem travessia nativa de grafos.

Fase 2: SaaS de Grafo de Terceiros

Em 2021, o Airbnb adotou um banco de dados de grafos gerenciado (PaaS). Isso melhorou a escalabilidade horizontal e introduziu uma linguagem de consulta real (Gremlin). No entanto, novos desafios surgiram:

• Latência de cauda longa: Nós com alto fator de expansão causavam picos imprevisíveis no P99.
• Instabilidade operacional: Reinicializações manuais periódicas eram necessárias para manter o desempenho.
• Controle limitado: Indexação fina e ajuste de consultas eram difíceis ou impossíveis.
• Vendor lock-in: Migrar para outra solução seria caro.

Fase 3: Infraestrutura Interna de Knowledge Graph

Em 2024, o Airbnb construiu uma plataforma de grafos baseada em JanusGraph (banco de dados de grafos distribuído open source) com DynamoDB como backend de armazenamento e OpenSearch para indexação. O grafo de identidade foi o primeiro tenant a migrar.

Por que JanusGraph + DynamoDB?

• Separação de armazenamento permitiu usar a escalabilidade comprovada do DynamoDB enquanto controlava a lógica do grafo.
• A linguagem Gremlin foi preservada, facilitando a migração.
• Código aberto significava visibilidade total e capacidade de fazer patches.

// Exemplo de consulta Gremlin usada no grafo de identidade
// Encontra todas as contas ligadas a um usuário em até 3 saltos
g.V().has('user_id', 'usuario_alvo')
  .repeat(__.bothE('conta_ligada').otherV().simplePath())
  .times(3)
  .path()
  .limit(100)

Otimizações Chave para Performance

Para atender aos requisitos de latência do Airbnb, o time fez várias mudanças profundas no motor JanusGraph:

1. Transações otimizadas: Substituiu o locking padrão do JanusGraph por writes condicionais e APIs de transação do DynamoDB, reduzindo overhead e mantendo integridade.
2. Execução paralela de consultas: A interface getMultiSlices foi melhorada para buscar dados em paralelo, cortando a latência em consultas com alto fan-out (ex: um usuário com milhares de contas ligadas).
3. Reescrita de consultas no cliente:
   • Remoção de steps Path onde possível, substituindo por verificações acíclicas condicionais para evitar consultas lentas não batch.
   • Otimização de steps side-effect para minimizar computação em operações de agregação.
4. Observabilidade: Integração do tracing distribuído do Airbnb no fork interno, fechando a lacuna de observabilidade do open source.

// Exemplo simplificado de otimização de consulta no cliente
// Antes: usando path() step (pode ser lento)
// Depois: usando dedup() e where() para garantir resultados acíclicos
g.V().has('user_id', 'alvo')
  .repeat(__.bothE('ligado').otherV().dedup())
  .times(3)
  .where(without('visitados'))
  .dedup()

Estratégia de Migração: Lado a Lado com Tráfego Sombra

O Airbnb não virou uma chave. A migração usou uma abordagem cuidadosa de tráfego sombra:

1. A solução antiga (vendor) e a nova solução interna rodaram em paralelo.
2. Ambos os motores suportavam Gremlin, então consultas idênticas puderam ser comparadas lado a lado.
3. Após o benchmark confirmar que a solução interna atendia aos requisitos de latência e throughput, o tráfego de produção foi gradualmente transferido.

Resultados: O que o Airbnb Ganhou?

Limitações e Cuidados

• JanusGraph não é bala de prata. Requer expertise operacional significativa para ajuste, especialmente para workloads com alto fan-out.
• Separação de armazenamento adiciona complexidade. Gerenciar JanusGraph e DynamoDB significa mais partes móveis que uma solução all-in-one.
• Otimização de consultas Gremlin ainda é manual. A reescrita descrita acima exigiu entendimento profundo tanto dos dados quanto do motor de consultas.
• Nem todos os casos de uso se beneficiam igualmente. Consultas com poucos saltos (1–2) podem não ver ganhos dramáticos; os maiores ganhos estão em travessias multi-salto.

Conclusão: Construir vs. Comprar — Um Ponto de Dados para Sua Arquitetura

A jornada do Airbnb é um case study poderoso para qualquer equipe considerando uma infraestrutura de knowledge graph. A decisão de construir uma plataforma interna compensou em:

• Performance: 10x mais throughput de escrita e latência P99 significativamente menor.
• Controle: Capacidade total de ajustar, corrigir e evoluir o motor de grafos.
• Estabilidade: Sem mais reinicializações manuais, resolução de incidentes mais rápida.

No entanto, essa abordagem não é para todos. Se seu workload de grafos é pequeno (< 1B arestas) ou seu time não tem expertise em bancos de grafos, um PaaS gerenciado ainda pode ser a escolha certa. Mas se você está escalando para bilhões de nós e precisa de consultas de travessia abaixo de 100ms, o caminho interno vale a pena considerar.

Próximos passos para seu aprendizado:

• Controlando Determinismo de Ponto Flutuante em CUDA: Um Mergulho na Nova API do CUB — outro mergulho em infraestrutura crítica de performance.
• Construindo o Gráfico de Pizza Perfeito em CSS: Uma Abordagem Semântica e Acessível — um domínio completamente diferente, mas mostra o mesmo princípio de escolher a ferramenta certa para o trabalho.

Fonte: Esta análise é baseada no post da Engenharia do Airbnb sobre Escalando o grafo de identidade do Airbnb com uma infraestrutura unificada de knowledge graph.