Concevoir une infrastructure de real-time bidding pour 100K QPS

Une bid request arrive de l'ad exchange. L'infrastructure d'enchères dispose de 10ms pour évaluer l'impression, la scorer face aux campagnes actives, calculer un prix d'enchère et renvoyer une réponse.

Ratez l'échéance et l'impression est perdue. Il n'y a pas de seconde tentative. À 100 000+ QPS, même un taux de timeout de 1% représente 1000 opportunités perdues par seconde.

Colocaliser les bidders avec les exchanges pour récupérer du temps d'évaluation

La latence réseau entre le bidder et l'ad exchange réduit directement le temps disponible pour l'évaluation de l'enchère. Un bidder situé à 50ms de distance réseau de l'exchange a déjà perdu avant même que son code ne s'exécute.

Les équipes de développement DSP qui colocalisent leurs instances de bidder avec les principaux exchanges récupèrent des millisecondes critiques :

• Un déploiement dans 6-8 data centers mondiaux récupère 5-15ms de temps d'évaluation par requête par rapport à un déploiement centralisé
• Les groupes d'auto-scaling de chaque région suivent les profils de trafic - US East atteint son pic aux heures ouvrées pendant que l'APAC réduit la voilure
• Les instances régionales de bidder conservent des copies locales des données de ciblage des campagnes, synchronisées toutes les 5-10 secondes depuis le référentiel central
• Les câbles à fibre optique entre centres de données transportent le trafic de synchronisation, mais le chemin d'évaluation des enchères ne franchit jamais les frontières régionales

Éliminer les allocations mémoire du chemin critique d'évaluation des enchères

À 100K QPS, les schémas d'allocation mémoire déterminent si le système tient son budget de latence. Les pauses de garbage collection, invisibles à 100 QPS, deviennent catastrophiques à grande échelle.

Le chemin d'évaluation des enchères repose sur des techniques précises :

• Tables de correspondance pré-calculées pour les critères de ciblage des campagnes, les capping de fréquence et les contraintes budgétaires - mises à jour de façon asynchrone toutes les 5-10 secondes depuis le référentiel principal des campagnes
• Pooling d'objets et allocation par arènes pour éliminer complètement les allocations tas par requête
• Des structures de données sans verrou pour l'état partagé - filtres de Bloom pour le capping de fréquence, compteurs atomiques pour le pacing du budget
• Des arbres de décision pré-construits pour l'évaluation du ciblage - construire l'arbre coûte des secondes, l'évaluer coûte des microsecondes

Zéro allocation sur le hot path n'est pas une optimisation. C'est une exigence à 100K QPS.

Exécuter l'inférence du modèle ML en moins de 3ms par enchère

Les modèles de prédiction du taux de clic et de probabilité de conversion doivent exécuter leur inférence en 2-3ms au sein du pipeline global d'évaluation des enchères. Chaque milliseconde consacrée à l'inférence n'est plus disponible pour le reste de la logique d'enchère.

ONNX Runtime avec des modèles quantifiés INT8 offre le meilleur compromis entre latence et précision :

• Extraction des features de la bid request en moins de 0.5ms grâce à des feature stores pré-calculés avec les signaux utilisateur et contextuels
• Inférence des modèles en 1-2ms via une évaluation ONNX par lots avec exécution épinglée aux threads - aucun changement de contexte pendant le scoring
• Calibration du score et calcul du prix d'enchère en moins de 0.5ms grâce à des courbes de prix pré-calculées par palier de campagne
• Mises à jour de modèle déployées en bascule blue-green — le nouveau modèle se charge en mode shadow, se valide face aux prédictions de production, puis bascule de façon atomique

Superviser à grande échelle sans alourdir le chemin d'enchère

La journalisation classique à 100K QPS génère plus de charge que la logique d'enchères elle-même. La stack de monitoring doit être aussi soucieuse de performance que l'application :

• Collecte de métriques par échantillonnage - journalisez en détail 1 requête sur 1000 et agrégez le reste dans des compteurs et histogrammes mis à jour atomiquement
• Suivi des percentiles en temps réel aux p50, p95 et p99, par région, par ad exchange et par palier de campagne
• Des circuit breakers automatiques retirent une instance de bidder de la rotation lorsque ses temps de réponse p99 dépassent le timeout de l'exchange
• Détection d'anomalies sur les baisses du taux d'enchère, les variations du win rate et les écarts de vitesse de dépense - repérer les modèles obsolètes et la dégradation réseau plus vite que la surveillance du taux d'erreur

Gérer le côté SSP de l'équation des enchères

Une supply-side platform fait face au problème miroir. Elle diffuse les bid requests à des dizaines de bidders, collecte les réponses, évalue les prix planchers, exécute l'enchère et renvoie un gagnant - le tout dans son propre timeout serré.

Les équipes de développement SSP font face à une complexité supplémentaire :

• Le header bidding, c'est lancer plusieurs enchères en parallèle - le timeout de chaque bidder constitue le budget de latence du SSP
• L'optimisation du prix plancher par modèles ML doit s'exécuter dans la même fenêtre d'enchère sans ajouter de latence
• Une logique d'enchère haute performance évalue 20-50 réponses d'enchère par impression et sélectionne le gagnant en moins de 1ms

La publicité programmatique à grande échelle exige que les deux côtés de l'enchère optimisent sans relâche la faible latence.

Adapter l'infrastructure d'enchères aux applications mobiles et à l'inventaire in-app

Les bid requests in-app portent des signaux différents de ceux des requêtes web. Les identifiants au niveau de l'appareil (quand ils sont disponibles), le contexte applicatif et la visibilité remontée par le SDK remplacent les signaux issus des cookies.

Les modèles de taux de clic entraînés sur l'inventaire web doivent être réentraînés pour les contextes in-app, où les schémas d'interaction des utilisateurs diffèrent sensiblement.

• La modélisation d'attribution sur mobile impose une intégration de postbacks server-to-server avec les MMP
• La déduplication sur plusieurs fenêtres d'attribution évite de compter deux fois les conversions
• Le rapprochement probabiliste et déterministe des correspondances s'exécute de façon asynchrone — les résultats alimentent le modèle d'enchères sous 24 heures