Pontuação de fraude em tempo real em escala

A pontuação de fraude em escala exige uma arquitetura fundamentalmente diferente do processamento em lote. Quando um pagamento está sendo autorizado ou uma conta está sendo criada, você tem milissegundos — não minutos — para entregar uma pontuação de risco. Na tracio.ai, processamos mais de 50.000 eventos por segundo com latência de pontuação mediana de 22ms. Este artigo explica a arquitetura que torna isso possível.

O pipeline de pontuação

Cada evento que chega entra em um pipeline de três estágios: enriquecimento de sinais, computação de vetores e pontuação de risco. O enriquecimento de sinais anexa dados de inteligência de dispositivos — a impressão digital do visitante, os resultados de detecção de bots, a inteligência de IP e o comportamento histórico — ao evento bruto. A computação de vetores transforma esses sinais enriquecidos em um vetor de features de comprimento fixo, otimizado para o nosso modelo de pontuação. A pontuação de risco passa o vetor pelo nosso modelo treinado e retorna uma pontuação entre 0.0 e 1.0.

A principal decisão de projeto é que o enriquecimento e a computação de vetores são separados da pontuação. Os dados de enriquecimento são pré-computados e armazenados em cache. Quando um visitante carrega uma página, computamos seu perfil de dispositivo e o armazenamos no Redis com um TTL de 60 minutos. Quando uma requisição de pontuação chega — normalmente disparada por um pagamento ou login — recuperamos o perfil pré-computado em vez de recomputá-lo. Isso reduz a latência de pontuação de mais de 200ms para menos de 30ms.

Processamento de streams com Go

Nossa camada de ingestão é escrita em Go e usa uma arquitetura de fan-out. Os eventos que chegam vêm via HTTP POST e são imediatamente colocados em um canal interno. Um pool de goroutines de trabalho lê desse canal, realiza o enriquecimento e grava os eventos enriquecidos no ClickHouse para análises e em uma fila de pontuação para processamento em tempo real. O pool de fan-out escala dinamicamente com base na profundidade da fila.

Escolhemos Go para a camada de ingestão por causa de suas excelentes primitivas de concorrência e alocação de memória previsível. Cada goroutine de trabalho consome aproximadamente 4KB de espaço de stack, permitindo executar milhares de workers concorrentes em um único nó. As pausas de menos de um milissegundo do coletor de lixo são críticas para manter uma latência consistente com alto throughput.

Cache na edge e vetores de sinal

Para nossos clientes de maior volume, implantamos modelos de pontuação na edge usando um cache de vetores de sinal pré-computados. Quando um dispositivo é visto pela primeira vez, computamos seu vetor de sinal completo e o armazenamos no nosso cache de edge (implantado no Cloudflare Workers KV). Requisições de pontuação subsequentes para o mesmo dispositivo recuperam o vetor em cache e executam a pontuação localmente na edge, atingindo latência de menos de 10ms.

O modelo de pontuação na edge é uma versão destilada do nosso modelo completo — menor e mais rápido, mas otimizado para os mesmos objetivos de precisão. Retreinamos o modelo da edge semanalmente e implantamos atualizações por meio de rolling deployment para evitar tempestades de invalidação de cache. O modelo completo roda do lado do servidor para casos em que a confiança do modelo da edge está abaixo de um limiar configurável.

ClickHouse para análises

Todos os eventos enriquecidos são armazenados no ClickHouse, nosso banco de dados analítico colunar. A compressão e o desempenho de consultas do ClickHouse nos permitem armazenar bilhões de eventos ao mesmo tempo em que damos suporte a consultas analíticas em tempo real. Nossos clientes usam essas análises para entender padrões de fraude, ajustar limiares de pontuação e investigar eventos individuais.

Usamos visualizações materializadas no ClickHouse para manter métricas pré-agregadas: taxa de fraude por país, distribuição de pontuação por tipo de dispositivo e taxas de falsos positivos por limiar. Essas visualizações materializadas se atualizam em tempo real à medida que os eventos chegam, fornecendo métricas prontas para dashboards sem consultas de agregação custosas.

Lições aprendidas

Construir um sistema de pontuação em tempo real nos ensinou várias lições. Primeiro, a pré-computação é a otimização mais importante — todo trabalho que você consegue fazer antes de a requisição de pontuação chegar é trabalho que não conta contra o seu orçamento de latência. Segundo, o modelo de concorrência do Go é bem adequado ao processamento de eventos de alto throughput, mas é preciso ser disciplinado quanto à alocação de memória para evitar pressão de GC. Terceiro, a implantação na edge é transformadora para a latência, mas exige gestão cuidadosa de modelos para evitar previsões desatualizadas.