Karolina Bendryk
Marta KravsProgrammatic's scale problem starts with a number: industry estimates put global bid request volume across the programmatic ecosystem at roughly 10 million QPS (Queries Per Second) at peak, with each auction required to resolve in under 200 milliseconds. Technically, modern ad serving and bidding infrastructure can scale to handle millions of QPS. But scalability on paper and stable performance under real load are two different things.
So, how scalable ad serving infrastructure actually is?
In this article, we break down the key factors behind real-world scalability. Instead of focusing on autoscaling configs, we evaluate real scenarios and assess the weak points where infrastructure tends to buckle first.
TL;DR
Global bid requests peak near 10 million QPS, and every auction has to close in under 200ms.
Real scalability means stable latency under sustained load, not just handling a traffic spike.
DSPs enforce strict QPS limits — Google tightens accuracy to 1–2% past 45K QPS.
Infrastructure usually breaks in the layers around the bidder: ID sync, reporting, unfiltered traffic.
The traffic shaping programmatic feature filters out low-value requests early, making scaling cheaper than just adding servers.
What "scalable" actually means in RTB
A full Real-Time Bidding (RTB) auction cycle — from bid request to creative render — typically has to close in under 200 milliseconds, and DSPs often work within a timeout window of 100ms or less. Miss that window, and the bid doesn't count.
That timing constraint is why "scalable" means something specific here. It's not just about accepting more requests — it's about keeping RTB auction latency stable while you do it. An ad serving and bidding infrastructure that handles 10x the traffic but sees response times start swinging wildly isn't actually scaling. It's technically absorbing load while quietly falling apart. Rising latency variance, not raw throughput, is usually the first sign something's wrong.
What QPS limits actually control
Queries per second in adtech is the number of bid requests an SSP sends to a DSP every second. DSPs set these QPS limits based on their own infrastructure capacity and the historical traffic quality they've seen from that specific SSP. Send too much low-quality traffic, and your QPS ad serving allocation shrinks accordingly.
Google Authorized Buyers is a useful reference point for how strict this enforcement actually gets. Its Callout Quota System governs exactly this: above 15K QPS, it generally holds to within 10% of the configured limit. Push past 45K QPS, and that tightens further — typically within 5%, often landing at just 1–2%. This pattern with QPS ad serving metrics holds across the entire industry. In fact, the bigger the scale a bidder operates at, the less room there is for traffic to drift past what the infrastructure is built to handle.
The hidden infrastructure cost of scale
Take an SSP sending 100,000 QPS of bid requests — a scale AWS itself calls "moderate" for a large platform. Per AWS's own modeling, that works out to 8.64 billion bid requests a day, or roughly 259.2 billion a month. At an average bid request size of 3 KB, and factoring in a realistic traffic split across regions and destinations, that generates nearly 725 TB of monthly egress traffic alone.
The takeaway: QPS growth doesn't scale in isolation. Every increase in request volume compounds compute load, storage, and network egress the bidding infrastructure cost simultaneously. Ad serving and bidding infrastructure scalability here is never just a technical question — it's a financial one, and the bill scales right alongside the traffic. To build a truly scalable ad serving infrastructure, marketers should focus on handling the weak points first.
Where infrastructure typically breaks first
The bidder itself is rarely where things fall apart first. Core bidding logic tends to get the most engineering attention, the most load testing, and the most scrutiny — it's the obvious bottleneck, so it's usually the one teams over-engineer against. But such real-time bidding scalability is not a complete solution. The failures show up one layer over, in the systems that support the bidder rather than the bidder itself.
ID synchronization between DSPs and SSPs is a common first casualty. Cookie and ID sync has to run constantly, matching identifiers across platforms so that targeting and frequency capping actually work downstream. This gets harder with server side bidding, where the match happens between servers instead of in a user's browser — there's no cookie dropped client-side to lean on, so sync has to hold up under the same load as the auction itself. Under peak load, sync calls start competing with bid requests for the same compute and network resources, and latency creeps up in a part of the stack nobody's watching closely.
Real-time reporting is the second common failure point. Every bid, win, loss, and impression needs to be logged and aggregated, often close to real time, so that pacing, budget controls, and optimization algorithms have current data to work with. At scale, that reporting pipeline has to process the same volume as the bidding pipeline. Sometimes, even more, since a single auction can generate multiple downstream events. When reporting programmatic bidding infrastructure lags, it doesn't crash the bidder, but it does mean campaigns run on stale data, which quietly degrades performance without ever throwing an obvious error.
The third pressure point is filtering — specifically, how early low-value traffic gets filtered out. If an SSP sends every available bid request downstream without any pre-filtering, a huge share of that volume ends up counting against the DSP's QPS quota before anyone determines it was never going to result in a bid. That's wasted infrastructure spend on both sides: the SSP pays to send it, the DSP pays to receive and evaluate it, and neither party gets a transaction out of it.
This is exactly why traffic shaping and QPS optimization have become standard practice rather than optional tuning. Instead of treating all inbound traffic equally, platforms use historical bidding behavior, inventory characteristics, and real-time signals to predict which requests are actually likely to result in a bid — and filter out the rest before they consume compute, bandwidth, or QPS allocation. The logic is straightforward: it's cheaper to decide a request isn't worth sending than it is to process it end-to-end and get a no-bid response anyway. Done well, this shifts scalability from a brute-force problem into an efficiency problem.
Final thoughts
Scalability in ad serving, as well as real-time bidding scalability, isn't measured by how high the QPS number can go. It's measured by whether latency and system behavior stay stable once that load is sustained, not just handled in a burst. Any programmatic bidding infrastructure can absorb a spike for a few minutes. The real test is what happens after hours of peak traffic, when the cracks that don't show up in a load test start showing up in production.
Platforms that invest in traffic shaping and QPS optimization end up scaling cheaper and more reliably than those that just throw more servers at the problem. Filtering out low-value traffic before it consumes infrastructure resources isn't a nice-to-have efficiency tweak — it's the difference between scaling that pays for itself and scaling that just moves the cost around without solving it.
That's exactly where TeqBlaze, a company with strong adtech expertise and a set of tools aimed at increasing programmatic efficiency, is ready to help you.
FAQ
What is QPS in programmatic advertising?
QPS (queries per second) is the number of bid requests an SSP sends to a DSP every second. It's the core unit for measuring load in real-time bidding.
How fast does a real-time bidding auction actually happen?
A full RTB cycle — from bid request to creative render — typically closes in under 200ms. DSPs often work within an even tighter window:
100ms or less is a common response budget
Miss the deadline, and the bid simply doesn't count
No retries, no grace period
Why do DSPs set QPS limits on SSP traffic?
Limits protect the DSP's infrastructure from more traffic than it can process, and they reflect trust: SSPs sending consistently low-quality traffic get smaller QPS allocations over time. There's also a supply path latency angle — every extra hop or under-optimized route adds delay before a bid ever reaches the DSP. QPS limits double as a filter against paths that waste cycles without improving win rates. It's less a hard cap and more a running scorecard.
What's the difference between scaling and stable scaling?
Scaling means accepting more requests. Stable scaling means doing that without latency creeping up or getting unpredictable. Ad server scalability is really a test of the second definition, not the first — a system that handles 10x the volume but responds inconsistently isn't actually scaling. It's degrading slowly while the dashboard still looks fine.
How can publishers reduce wasted QPS?
Filter low-value traffic before it's sent, not after it's processed
Use traffic shaping to prioritize requests likely to convert
Lean on historical bid data to predict which inventory a DSP will actually bid on
Avoid sending full, unfiltered volume to every DSP by default
Filtering earlier means paying less to process traffic that was never going to result in a bid.
