Além do SaaS: Como estamos escalando um knowledge graph unificado na Aeriva.io

Por Equipe de Engenharia de Core Systems da Aeriva.io

A representação de relacionamentos complexos entre entidades em tempo real é um dos maiores desafios de data engineering da atualidade.

Na Aeriva.io, entendemos que sistemas modernos de antifraude, Trust & Safety e resolução de identidade não podem ficar reféns de latências de cauda longa ($P99$) ou do aprisionamento tecnológico (vendor lock-in) de plataformas de prateleira (PaaS).

Neste artigo, detalhamos como redesenhamos e migramos um grafo de identidade massivo — composto por 7 bilhões de nós e 11 bilhões de arestas — de uma infraestrutura legada e fragmentada para a nossa arquitetura unificada de Grafo de Conhecimento Interno.

O resultado? Escalabilidade linear de escrita e previsibilidade de leitura mesmo sob queries de múltiplos saltos (multi-hop traversal).

O Desafio de Escala do Grafo de Identidade

O grafo de identidade processa o fluxo contínuo de interações de usuários para detectar atividades maliciosas e contas vinculadas em tempo quase real (near real-time). À medida que a densidade da malha aumentava, enfrentávamos quatro gargalos críticos:

• Escrita de Alta Volatilidade: Ingestão assíncrona orientada a eventos absorvendo mais de 5 milhões de novas arestas por dia.
• Complexidade de Travessia ($4\text{ a }8\text{ hops}$): Consultas profundas que precisavam responder sob rígidos SLAs de microsserviços de borda.
• O Efeito "Super-Nó" (High-Degree Nodes): Vértices com alta conectividade geravam degradação exponencial de performance, inflando desproporcionalmente a latência de cauda ($P95$ e $P99$).
• Antipadrões de Armazenamento: A abordagem legada oscilava entre junções SQL dispendiosas, snapshots em lote (batch offline) e soluções SaaS com caixas-pretas operacionais e custos proibitivos.

A Arquitetura Core: Desacoplamento de Computação e Persistência

Para mitigar essas limitações, a Aeriva.io implementou uma pilha nativa e altamente customizável baseada no motor distribuído JanusGraph (compatível com Apache TinkerPop / Gremlin), utilizando o AWS DynamoDB como backend plugável de armazenamento e o

OpenSearch para indexação secundária.

+-------------------------------------------------------------+ | Camada de Clientes / APIs | +-------------------------------------------------------------+ | (Query Engine / Gremlin) v +-------------------------------------------------------------+ | Aeriva

Graph Service (JanusGraph Custom Fork) | | - Transações Condicionais - Otimizador de Query (Gremlin) | +-------------------------------------------------------------+ | | v (Persistência) v (Indexação) +--------------------+ +-----------------------+ | AWS

DynamoDB | | OpenSearch | +--------------------+ +-----------------------+

Por que essa arquitetura é disruptiva?

Ao isolar completamente a camada lógica de computação gráfica da persistência física de dados, conseguimos provisionar e escalar recursos de IOPS independentemente do poder computacional de travessia.

O DynamoDB nos garante tolerância a falhas global, enquanto mantemos controle absoluto sobre o ciclo de vida e estrutura do grafo.

Otimizações de Engenharia a Nível de Kernel

A simples adoção de tecnologias open-source não resolve problemas de escala hiperbólica. Nossos engenheiros introduziram modificações proprietárias no core do engine:

1. Transações Otimizadas sem Lock Concorrente

O mecanismo padrão de locking do JanusGraph gerava gargalos severos em escritas concorrentes.

Substituímos essa abordagem por uma estratégia de gravação condicional nativa nas APIs do DynamoDB, movendo a garantia de atomicidade para a camada de persistência com sobrecarga computacional próxima de zero.

2. Paralelização de Grafo com getMultiSlices

Customizamos a interface de busca para executar varreduras em paralelo no backend de armazenamento. Quando o motor encontra um nó de alta ramificação, o fanning-out da consulta é distribuído concorrentemente entre threads isoladas, achatando a curva de latência $P99$.

3. Engenharia de Query do Lado do Cliente (Gremlin)

Nem todos os planos de execução de consulta nascem iguais. Reescrevemos compiladores internos para otimizar etapas do TinkerPop:

• Eliminação de Path / SimplePath: Passos de caminho tradicionais impedem buscas em lote (batching). Substituímos essas etapas por sequências de consultas condicionais acíclicas parametrizadas.
• Minimização de Efeitos Colaterais: Otimizamos o planejamento de queries de agregação para forçar o agrupamento (compaction) antes do retorno do payload.

Resultados de Produção: Métricas que Redefinem o Mercado

A migração para a infraestrutura unificada da Aeriva.io validou nossa tese arquitetural com ganhos massivos de eficiência:

Métrica de Performance

Cenário Anterior (SaaS Fornecedor)

Nova Infraestrutura Aeriva.io

Impacto Real

Latência $P99$ (Read)

Alta Variabilidade / Cauda Longa

Linear e Previsível

Redução drástica em timeouts

Escalabilidade de Escrita

Limitação de Throttling

$10\times$ mais QPS de gravação

Suporte a picos massivos de tráfego

Resiliência Operacional

Reinicializações semanais necessárias

Zero Downtime (Auto-scaling)

Eliminação de intervenção manual

O Futuro dos Dados Conectados na Aeriva.io

A consolidação deste grafo de identidade prova que a independência de infraestrutura não apenas reduz o custo total de propriedade (TCO), mas desbloqueia capacidades analíticas antes impossíveis.

Nosso roadmap agora avança para a integração nativa de algoritmos de Graph Neural Networks (GNNs) em tempo real diretamente na nossa camada de cache.

Quer entender como a infraestrutura de grafos da Aeriva.io pode transformar a detecção de fraude e a resolução de identidades da sua empresa com performance sub-milissegundo?