Scoring de fraude en tiempo real a escala

El scoring de fraude a escala requiere una arquitectura fundamentalmente distinta a la del procesamiento por lotes. Cuando se está autorizando un pago o creando una cuenta, se dispone de milisegundos —no de minutos— para entregar una puntuación de riesgo. En tracio.ai procesamos más de 50,000 eventos por segundo con una latencia de scoring mediana de 22ms. Este artículo explica la arquitectura que lo hace posible.

El pipeline de scoring

Cada evento entrante entra en un pipeline de tres etapas: enriquecimiento de señales, cálculo de vectores y scoring de riesgo. El enriquecimiento de señales adjunta datos de inteligencia de dispositivos —la huella del visitante, los resultados de detección de bots, la inteligencia de IP y el comportamiento histórico— al evento en bruto. El cálculo de vectores transforma estas señales enriquecidas en un vector de características de longitud fija optimizado para nuestro modelo de scoring. El scoring de riesgo pasa el vector por nuestro modelo entrenado y devuelve una puntuación entre 0.0 y 1.0.

La decisión de diseño clave es que el enriquecimiento y el cálculo de vectores están separados del scoring. Los datos de enriquecimiento se precalculan y se cachean. Cuando un visitante carga una página, calculamos su perfil de dispositivo y lo almacenamos en Redis con un TTL de 60 minutos. Cuando llega una solicitud de scoring —normalmente activada por un pago o un inicio de sesión—, recuperamos el perfil precalculado en lugar de volver a calcularlo. Esto reduce la latencia de scoring de más de 200ms a menos de 30ms.

Procesamiento de streams con Go

Nuestra capa de ingesta está escrita en Go y usa una arquitectura de fan-out. Los eventos entrantes llegan mediante HTTP POST y se colocan de inmediato en un canal interno. Un pool de goroutines de trabajo lee de este canal, realiza el enriquecimiento y escribe los eventos enriquecidos en ClickHouse para analítica y en una cola de scoring para el procesamiento en tiempo real. El pool de fan-out escala dinámicamente según la profundidad de la cola.

Elegimos Go para la capa de ingesta por sus excelentes primitivas de concurrencia y su asignación de memoria predecible. Cada goroutine de trabajo consume aproximadamente 4KB de espacio de stack, lo que nos permite ejecutar miles de workers concurrentes en un solo nodo. Las pausas del recolector de basura, de menos de un milisegundo, son críticas para mantener una latencia consistente con un alto rendimiento.

Caché en el edge y vectores de señales

Para nuestros clientes de mayor volumen, desplegamos modelos de scoring en el edge usando una caché de vectores de señales precalculados. Cuando se ve un dispositivo por primera vez, calculamos su vector de señales completo y lo almacenamos en nuestra caché de edge (desplegada en Cloudflare Workers KV). Las solicitudes de scoring posteriores para el mismo dispositivo recuperan el vector cacheado y ejecutan el scoring localmente en el edge, alcanzando una latencia inferior a 10ms.

El modelo de scoring del edge es una versión destilada de nuestro modelo completo: más pequeño y rápido, pero optimizado para los mismos objetivos de precisión. Reentrenamos el modelo del edge cada semana y desplegamos las actualizaciones mediante despliegue progresivo para evitar tormentas de invalidación de caché. El modelo completo se ejecuta en el servidor para los casos en los que la confianza del modelo del edge está por debajo de un umbral configurable.

ClickHouse para analítica

Todos los eventos enriquecidos se almacenan en ClickHouse, nuestra base de datos analítica columnar. La compresión y el rendimiento de consultas de ClickHouse nos permiten almacenar miles de millones de eventos a la vez que damos soporte a consultas analíticas en tiempo real. Nuestros clientes usan esta analítica para comprender los patrones de fraude, ajustar los umbrales de scoring e investigar eventos individuales.

Usamos vistas materializadas en ClickHouse para mantener métricas preagregadas: tasa de fraude por país, distribución de scoring por tipo de dispositivo y tasas de falsos positivos por umbral. Estas vistas materializadas se actualizan en tiempo real a medida que llegan los eventos, proporcionando métricas listas para el dashboard sin costosas consultas de agregación.

Lecciones aprendidas

Construir un sistema de scoring en tiempo real nos enseñó varias lecciones. Primera: el precálculo es la optimización más importante; todo el trabajo que pueda hacer antes de que llegue la solicitud de scoring es trabajo que no cuenta contra su presupuesto de latencia. Segunda: el modelo de concurrencia de Go se adapta bien al procesamiento de eventos de alto rendimiento, pero hay que ser disciplinado con la asignación de memoria para evitar la presión sobre el GC. Tercera: el despliegue en el edge es transformador para la latencia, pero requiere una gestión cuidadosa del modelo para evitar predicciones obsoletas.