Airbnb troca PaaS de grafo por infra interna unificada
A engenharia do Airbnb publicou no Medium em maio a historia de como saiu de um identity graph rodando em PaaS de terceiro pra uma infra interna unificada de knowledge graph. A motivacao foi simples: performance e custo. A solucao interna superou o fornecedor anterior em todos os padroes testados de query.
O que e um identity graph
Identity graph mapeia relacoes entre identidades dentro do sistema: um mesmo usuario com varios devices, hosts e guests vinculados, contas duplicadas detectadas por sinais como email, telefone, payment method. Pra plataforma como Airbnb, ele e infraestrutura critica de antifraude, merge de contas e personalizacao.
O gargalo do PaaS
O sistema anterior rodava em PaaS de terceiro. O problema nao era escala vertical de leitura simples, era padroes especificos de consulta de grafo. Queries do tipo “todas as identidades a 3 hops de distancia que compartilham email ou device” rodavam lentas. Em escala Airbnb, isso machucava latencia da API de personalizacao e de risco em tempo real.
O desenho da infra interna
A decisao foi construir um knowledge graph unificado, capaz de absorver entidades de varios dominios (usuario, host, listing) num mesmo esquema. Isso elimina o problema de manter graphs separados por dominio e sincronizar. O artigo nao detalha tecnologia subjacente especifica (se Neo4j fork, JanusGraph customizado ou build proprio), mas detalha o schema unificado e o modelo de versionamento.
A migracao
A migracao foi feita com double-write: o sistema antigo continuou recebendo todas as escritas, e o novo passou a receber em paralelo. Periodo de validacao comparou resultados de query em milhares de cenarios reais. Quando o novo ficou consistentemente correto e mais rapido, leitura foi gradualmente migrada. So depois disso o antigo foi desativado. E o playbook padrao pra migracao de banco critico, mas execucao em escala Airbnb e o que rendeu o post.
O resultado
A solucao interna superou o PaaS anterior em todos os padroes testados de query. O ganho de latencia ponta a ponta na API de leitura foi significativo, segundo o post (numero exato nao foi publicado). Custo operacional tambem caiu porque a infra usa stack que Airbnb ja roda em outros lugares, sem licenca de terceiro.
A licao pra outros times
O caso e relevante pra empresas que mantem grafos de identidade em escala. O criterio pratico que sai do post: se a maior parte das queries do seu sistema sao padroes de grafo nao triviais (varios hops, joins por atributos cruzados, filtros condicionais profundos) e o volume justifica o custo de engenharia, build interno pode vencer. Pra workload de grafo raso ou volume modesto, PaaS continua razoavel.
Reportado originalmente por Airbnb Engineering em 2026-05.
