Ingeniería de infraestructura de pujas en tiempo real para 100K QPS

Llega una solicitud de puja desde el ad exchange. La infraestructura de pujas dispone de 10ms para evaluar la impresión, puntuarla frente a las campañas activas, calcular un precio de puja y devolver una respuesta.

Si se incumple el plazo, la impresión se pierde. No hay reintento. A 100.000+ QPS, incluso una tasa de timeouts del 1% supone 1.000 oportunidades perdidas por segundo.

Coubica los bidders con los exchanges para recuperar tiempo de evaluación

La latencia de red entre el bidder y el ad exchange reduce directamente el tiempo disponible para evaluar la puja. Un bidder a 50ms de distancia de red del exchange ya ha perdido antes de que se ejecute su código.

Los equipos de desarrollo de DSP que colocan sus instancias de bidder junto a los grandes exchanges recuperan milisegundos críticos:

• Desplegar en 6-8 centros de datos globales recupera 5-15ms de tiempo de evaluación por solicitud frente a un despliegue centralizado
• Los grupos de autoescalado de cada región responden a los patrones de tráfico: US East alcanza su pico en horario laboral mientras APAC reduce capacidad
• Las instancias regionales del bidder mantienen copias locales de los datos de segmentación de campañas, sincronizadas cada 5-10 segundos desde el almacén central
• Los cables de fibra óptica entre centros de datos transportan el tráfico de sincronización, pero la ruta de evaluación de pujas nunca cruza los límites regionales

Eliminar la asignación de memoria del hot path de evaluación de pujas

A 100K QPS, los patrones de asignación de memoria determinan si el sistema cumple su presupuesto de latencia. Las pausas del recolector de basura, invisibles a 100 QPS, se vuelven catastróficas a escala.

La ruta de evaluación de pujas emplea técnicas concretas:

• Tablas de búsqueda precalculadas para los criterios de segmentación de campañas, los límites de frecuencia y las restricciones de presupuesto, actualizadas de forma asíncrona cada 5-10 segundos desde el almacén principal de campañas
• Pooling de objetos y asignación en arena para eliminar por completo las asignaciones en heap por solicitud
• Estructuras de datos sin bloqueos para el estado compartido - filtros de Bloom para el frequency capping, contadores atómicos para el pacing del presupuesto
• Árboles de decisión precompilados para la evaluación del targeting - construir el árbol cuesta segundos, evaluarlo cuesta microsegundos

Cero asignaciones de memoria en el hot path no es una optimización. Es un requisito a 100K QPS.

Ejecutar la inferencia del modelo de ML en menos de 3ms por puja

Los modelos de predicción de tasa de clics y de probabilidad de conversión deben ejecutar la inferencia en 2-3ms como parte del pipeline general de evaluación de pujas. Cada milisegundo dedicado a la inferencia deja de estar disponible para el resto de la lógica de puja.

ONNX Runtime con modelos cuantizados INT8 ofrece el mejor equilibrio entre latencia y precisión:

• Extracción de features de la bid request en menos de 0.5ms usando feature stores precalculados con señales de usuario y de contexto
• Inferencia del modelo en 1-2ms mediante evaluación ONNX por lotes con ejecución fijada a hilos - sin cambios de contexto durante el scoring
• Calibración de la puntuación y cálculo del precio de puja en menos de 0.5ms usando curvas de precio precalculadas por nivel de campaña
• Actualizaciones de modelo desplegadas con conmutación blue-green - el nuevo modelo se carga en modo shadow, se valida contra las predicciones de producción y luego se intercambia de forma atómica

Monitoriza a escala sin añadir sobrecarga a la ruta de pujas

El logging tradicional a 100K QPS genera más carga que la propia lógica de pujas. El stack de monitoreo debe cuidar el rendimiento tanto como la aplicación:

• Recopilación de métricas por muestreo - registrar en detalle 1 de cada 1000 solicitudes y agregar el resto en contadores e histogramas actualizados atómicamente
• Seguimiento de percentiles en tiempo real en p50, p95 y p99 por región, por ad exchange y por nivel de campaña
• Circuit breakers automáticos que retiran una instancia del bidder de la rotación cuando sus tiempos de respuesta p99 superan el timeout del exchange
• Detección de anomalías en caídas de la tasa de pujas, cambios en la tasa de pujas ganadas y desviaciones en la velocidad de gasto: detecta modelos obsoletos y degradación de la red antes que el monitoreo de tasas de error

Gestionar el lado SSP de la ecuación de la subasta

Una plataforma del lado de la oferta se enfrenta al problema espejo. Difunde solicitudes de puja a decenas de postores, recopila las respuestas, evalúa los precios mínimos, ejecuta la subasta y devuelve un ganador - todo dentro de su propio timeout, igual de ajustado.

Los equipos de desarrollo de SSP se enfrentan a una complejidad adicional:

• El header bidding implica ejecutar múltiples subastas en paralelo - el timeout de cada bidder es el presupuesto de latencia de la SSP
• La optimización del floor price con modelos de ML debe ejecutarse dentro de la misma ventana de subasta sin añadir latencia
• Una lógica de subasta de alto rendimiento evalúa entre 20 y 50 respuestas de puja por impresión y selecciona al ganador en menos de 1ms

La publicidad programática a escala exige que ambos lados de la subasta optimicen sin descanso para lograr una latencia baja.

Adaptar la infraestructura de pujas al inventario de apps móviles e in-app

Las solicitudes de puja in-app llevan señales distintas de las de la web. Los identificadores a nivel de dispositivo (cuando están disponibles), el contexto de la app y la viewability reportada por el SDK sustituyen a las señales basadas en cookies.

Los modelos de tasa de clics entrenados con inventario web necesitan reentrenarse para contextos in-app, donde los patrones de interacción del usuario difieren sustancialmente.

• El modelado de atribución en móvil requiere integración de postbacks server-to-server con los MMP
• La deduplicación entre múltiples ventanas de atribución evita contar dos veces las conversiones
• La conciliación de coincidencias probabilísticas y deterministas se ejecuta de forma asíncrona: los resultados retroalimentan el modelo de puja en un plazo de 24 horas