Engenharia de infraestrutura de real-time bidding para 100K QPS

Uma bid request chega do ad exchange. A infraestrutura de bidding tem 10ms para avaliar a impressão, pontuá-la contra as campanhas ativas, calcular um preço de lance e devolver uma resposta.

Perdeu o prazo, a impressão se foi. Não há nova tentativa. A 100.000+ QPS, mesmo uma taxa de timeout de 1% significa 1.000 oportunidades perdidas por segundo.

Coloque os bidders em co-location com as exchanges para recuperar tempo de avaliação

A latência de rede entre o bidder e o ad exchange reduz diretamente o tempo disponível para avaliar o lance. Um bidder a 50ms de distância de rede da exchange já perdeu antes de o seu código rodar.

Times de desenvolvimento de DSP que mantêm instâncias de bidder em co-location com as grandes exchanges recuperam milissegundos críticos:

• Operar em 6-8 data centers globais recupera 5-15ms de tempo de avaliação por requisição em comparação com um deploy centralizado
• Grupos de auto-scaling em cada região respondem aos padrões de tráfego - o US East atinge o pico no horário comercial enquanto o APAC reduz a capacidade
• Instâncias regionais de bidder mantêm cópias locais dos dados de segmentação de campanha, sincronizadas a cada 5-10 segundos com o repositório central
• Cabos de fibra óptica entre data centers carregam o tráfego de sincronização, mas o caminho de avaliação do bid nunca cruza fronteiras regionais

Elimine a alocação de memória do hot path de avaliação de bids

A 100K QPS, os padrões de alocação de memória determinam se o sistema cumpre seu orçamento de latência. Pausas de garbage collection invisíveis a 100 QPS tornam-se catastróficas em escala.

O caminho de avaliação do lance usa técnicas específicas:

• Tabelas de lookup pré-computadas para critérios de segmentação de campanha, frequency caps e restrições de orçamento - atualizadas de forma assíncrona a cada 5-10 segundos a partir do repositório principal de campanhas
• Object pooling e arena allocation para eliminar por completo as alocações de heap por requisição
• Estruturas de dados sem locks para estado compartilhado - bloom filters para frequency capping, contadores atômicos para o pacing de orçamento
• Árvores de decisão pré-construídas para a avaliação de targeting - construir a árvore custa segundos, avaliá-la custa microssegundos

Zero alocação no hot path não é uma otimização. É um requisito a 100K QPS.

Rode a inferência do modelo de ML em menos de 3ms por lance

Modelos de previsão de click-through rate e de probabilidade de conversão precisam executar a inferência em 2-3ms como parte do pipeline geral de avaliação do lance. Cada milissegundo gasto em inferência deixa de estar disponível para o restante da lógica de lance.

O ONNX Runtime com modelos quantizados em INT8 oferece o melhor trade-off entre latência e acurácia:

• Extração de features do bid request em menos de 0.5ms usando feature stores pré-computados com sinais de usuário e de contexto
• Inferência de modelo em 1-2ms com avaliação ONNX em batch e execução com threads fixadas - sem troca de contexto durante o scoring
• Calibração de score e cálculo do preço do bid em menos de 0,5ms usando curvas de preço pré-computadas por tier de campanha
• Atualizações de modelo publicadas por blue-green switching - o novo modelo carrega em shadow mode, valida contra as previsões de produção e então troca atomicamente

Monitorar em escala sem adicionar overhead ao caminho do bidding

Logging tradicional a 100K QPS gera mais carga do que a própria lógica de bidding. A stack de monitoramento precisa ser tão consciente de performance quanto a aplicação:

• Coleta de métricas por amostragem - registre 1 a cada 1.000 requisições em detalhe e agregue o restante em contadores e histogramas atualizados atomicamente
• Acompanhamento de percentis em tempo real em p50, p95 e p99 por região, por ad exchange e por tier de campanha
• Circuit breakers automáticos que retiram uma instância de bidder da rotação quando seus tempos de resposta p99 excedem o timeout da exchange
• Detecção de anomalias em quedas da taxa de lances, mudanças de win rate e desvios na velocidade de gasto - identificando modelos desatualizados e degradação de rede mais rápido que o monitoramento por taxa de erro

Cuide do lado SSP da equação do leilão

Uma supply-side platform enfrenta o problema espelhado. Ela transmite bid requests a dezenas de compradores, coleta respostas, avalia preços mínimos, roda o leilão e devolve um vencedor - tudo dentro do seu próprio timeout apertado.

As equipes de desenvolvimento de SSP enfrentam complexidade adicional:

• Header bidding significa rodar vários leilões em paralelo - o timeout de cada bidder é o orçamento de latência do SSP
• A otimização de preço mínimo com modelos de ML precisa executar dentro da mesma janela de leilão sem adicionar latência
• A lógica de leilão de alta performance avalia 20-50 respostas de lance por impressão, escolhendo o vencedor em menos de 1ms

Publicidade programática em escala exige que os dois lados do leilão otimizem sem trégua para baixa latência.

Adaptar a infraestrutura de bidding para inventário de apps mobile e in-app

Bid requests in-app carregam sinais diferentes dos da web. Identificadores de dispositivo (quando disponíveis), contexto do app e viewability reportada pelo SDK substituem os sinais baseados em cookies.

Modelos de click-through rate treinados em inventário web precisam de retreinamento para contextos in-app, onde os padrões de interação do usuário são bem diferentes.

• A modelagem de atribuição em mobile exige integração de postback server-to-server com MMPs
• A deduplicação entre múltiplas janelas de atribuição evita contar conversões em dobro
• A reconciliação de matches probabilísticos e determinísticos roda de forma assíncrona - os resultados retornam ao modelo de bidding em até 24 horas