Real-Time-Bidding-Infrastruktur für 100K QPS bauen

Eine Bid Request trifft von der Ad Exchange ein. Die Bidding-Infrastruktur hat 10ms Zeit, die Impression zu bewerten, sie gegen aktive Kampagnen zu scoren, einen Gebotspreis zu berechnen und eine Antwort zurückzuliefern.

Wird die Frist verpasst, ist die Impression weg. Einen zweiten Versuch gibt es nicht. Bei 100.000+ QPS bedeutet selbst eine Timeout-Rate von 1% 1.000 verlorene Gelegenheiten pro Sekunde.

Bidder bei den Exchanges kolokieren, um Zeit für die Auswertung zurückzugewinnen

Netzwerklatenz zwischen Bidder und Ad Exchange verringert direkt die Zeit für die Gebotsbewertung. Ein Bidder mit 50ms Netzwerkdistanz zur Exchange hat bereits verloren, bevor sein Code läuft.

DSP-Entwicklungsteams, die Bidder-Instanzen bei großen Exchanges co-locaten, gewinnen entscheidende Millisekunden zurück:

• Ein Deployment in 6-8 globalen Rechenzentren gewinnt pro Request 5-15ms Bewertungszeit gegenüber einem zentralen Deployment zurück
• Auto-Scaling-Gruppen in jeder Region reagieren auf Traffic-Muster – US East erreicht Spitzen während der Geschäftszeiten, während APAC herunterskaliert
• Regionale Bidder-Instanzen halten lokale Kopien der Kampagnen-Targeting-Daten, alle 5-10 Sekunden mit dem zentralen Speicher synchronisiert
• Glasfaserstrecken zwischen den Rechenzentren transportieren den Synchronisationsverkehr, doch der Pfad der Gebotsbewertung überschreitet nie eine Regionsgrenze

Speicherallokation aus dem Hot Path der Bid-Auswertung entfernen

Bei 100K QPS entscheiden die Muster der Speicherallokation darüber, ob das System sein Latenzbudget einhält. Garbage-Collection-Pausen, die bei 100 QPS unsichtbar sind, werden im großen Maßstab katastrophal.

Der Pfad der Gebotsbewertung nutzt konkrete Techniken:

• Vorberechnete Lookup-Tabellen für Kampagnen-Targeting-Kriterien, Frequency Caps und Budgetgrenzen – asynchron alle 5-10 Sekunden aus dem zentralen Kampagnenspeicher aktualisiert
• Object Pooling und Arena-Allokation, um Heap-Allokationen pro Request vollständig zu vermeiden
• Lock-freie Datenstrukturen für gemeinsamen State – Bloom-Filter für Frequency Capping, atomare Zähler für Budget Pacing
• Vorgebaute Entscheidungsbäume für die Targeting-Auswertung – den Baum zu bauen kostet Sekunden, ihn auszuwerten Mikrosekunden

Null Allokationen auf dem Hot Path sind keine Optimierung. Bei 100K QPS sind sie Pflicht.

ML-Modell-Inferenz in unter 3ms pro Gebot ausführen

Modelle für Click-Through-Rate-Prognose und Conversion-Wahrscheinlichkeit müssen ihre Inferenz innerhalb von 2-3ms ausführen, als Teil der gesamten Bid-Evaluation-Pipeline. Jede Millisekunde für Inferenz fehlt der übrigen Bid-Logik.

ONNX Runtime mit quantisierten INT8-Modellen bietet das beste Verhältnis von Latenz zu Genauigkeit:

• Feature-Extraktion aus dem Bid Request in unter 0.5ms über vorberechnete Feature Stores mit Nutzer- und Kontextsignalen
• Modell-Inferenz in 1-2ms mittels gebündelter ONNX-Auswertung mit thread-gepinnter Ausführung – kein Context Switching während des Scorings
• Score-Kalibrierung und Berechnung des Gebotspreises in unter 0.5ms mithilfe vorberechneter Preiskurven je Kampagnen-Tier
• Modell-Updates werden per Blue-Green-Switching ausgerollt – das neue Modell lädt im Shadow Mode, validiert gegen die Vorhersagen aus der Produktion und wird dann atomar umgeschaltet

Monitoring im großen Maßstab, ohne den Bidding-Pfad zusätzlich zu belasten

Klassisches Logging bei 100K QPS erzeugt mehr Last als die Bidding-Logik selbst. Der Monitoring-Stack muss ebenso performancebewusst sein wie die Anwendung:

• Stichprobenbasierte Metrikerfassung – 1 von 1.000 Requests im Detail loggen, den Rest in atomar aktualisierten Countern und Histogrammen aggregieren
• Perzentil-Tracking in Echtzeit bei p50, p95 und p99 – je Region, je Ad Exchange, je Kampagnenstufe
• Automatische Circuit Breaker, die eine Bidder-Instanz aus der Rotation nehmen, sobald ihre p99-Antwortzeiten das Timeout der Exchange überschreiten
• Anomalieerkennung bei Einbrüchen der Bid Rate, Veränderungen der Win Rate und Abweichungen der Spend Velocity - erkennt veraltete Modelle und Netzwerkdegradation schneller als ein Monitoring der Fehlerrate

Die SSP-Seite der Auktionsgleichung abdecken

Eine Supply-Side-Platform löst dasselbe Problem spiegelverkehrt. Sie verteilt Bid Requests an Dutzende Bidder, sammelt die Antworten ein, bewertet Floor Prices, führt die Auktion durch und liefert einen Gewinner - alles innerhalb ihres eigenen knappen Timeouts.

SSP-Entwicklungsteams stehen vor zusätzlicher Komplexität:

• Header Bidding heißt, mehrere Auktionen parallel zu fahren – das Timeout jedes Bidders ist das Latenzbudget der SSP
• Floor-Price-Optimierung mit ML-Modellen muss innerhalb desselben Auktionsfensters laufen, ohne Latenz hinzuzufügen
• Hochperformante Auktionslogik bewertet 20-50 Bid Responses pro Impression und ermittelt den Gewinner in unter 1ms

Programmatic Advertising in großem Maßstab verlangt, dass beide Seiten der Auktion kompromisslos auf niedrige Latenz optimieren.

Bidding-Infrastruktur für Mobile-App- und In-App-Inventar anpassen

In-App-Bid-Requests transportieren andere Signale als Web-Requests. Geräte-Identifier (wo verfügbar), App-Kontext und vom SDK gemeldete Viewability ersetzen cookiebasierte Signale.

Click-Through-Rate-Modelle, die auf Web-Inventar trainiert wurden, brauchen ein erneutes Training für In-App-Kontexte, in denen sich die Interaktionsmuster der Nutzer deutlich unterscheiden.

• Attributionsmodellierung für Mobile erfordert Server-to-Server-Postback-Integration mit MMPs
• Deduplizierung über mehrere Attributionsfenster verhindert doppelt gezählte Conversions
• Der Abgleich probabilistischer und deterministischer Matches läuft asynchron – die Ergebnisse fließen innerhalb von 24 Stunden zurück in das Bidding-Modell