Infrastructure for Real-Time Bidding and Programmatic Advertising Platforms

An ad impression loads. In roughly the time it takes to blink, a live auction runs among dozens of bidders, a winner gets picked, and the ad renders. If your bid response lands one millisecond too late, it doesn’t get discounted. It gets thrown out entirely.

That’s not a metaphor. It’s how the OpenRTB protocol, the actual industry standard behind programmatic advertising, is built to work, and it makes real-time bidding one of the least forgiving latency environments in general-purpose computing.

What Actually Happens in the Auction Window

The OpenRTB specification, maintained by the IAB Tech Lab, includes a field called tmax: the maximum time in milliseconds an exchange will wait for bids before it stops listening. The spec doesn’t mandate a specific number, but real-world implementations converge tightly around one. Google, one of the largest ad exchanges, imposes a 100-millisecond timeout on the RTB process specifically. Independent measurements across the industry generally put the practical window between 80 and 120 milliseconds. Whatever the exact figure a given exchange uses, a demand-side platform’s bid has to travel out, get evaluated, and travel back inside that window, or it’s simply excluded from the auction, full stop, regardless of how competitive the bid actually was.

That’s a fundamentally different kind of latency requirement than most web infrastructure deals with. A slow page load is a bad experience. A bid response that misses its window isn’t degraded, it’s disqualified. Every millisecond spent on infrastructure overhead is a millisecond that isn’t available for your actual bidding logic to run.

Why Shared Infrastructure Quietly Costs You Auctions

A hypervisor layer between your application and the physical hardware adds processing overhead on every request, typically small in absolute terms, but RTB doesn’t have room for typically small. When your entire budget is measured in double-digit milliseconds and a chunk of it disappears to virtualization scheduling, noisy-neighbor contention from other tenants’ workloads, or unpredictable jitter on shared network paths, that’s not a rounding error. It’s a direct, measurable reduction in how many auctions your bids actually make it into.

This is the same underlying argument that applies to any latency-sensitive workload on shared cloud infrastructure, but RTB makes the cost of that overhead unusually easy to quantify: a bid that misses the window doesn’t get delivered slowly, it gets thrown out and the opportunity to bid is simply gone. Dedicated, single-tenant bare metal removes the specific sources of that variance, no hypervisor layer absorbing part of your window, no other tenant’s traffic competing for the same physical NIC or CPU cycles.

Geography Still Sets the Floor

Removing virtualization overhead doesn’t make network physics negotiable. Light in fiber travels at a fixed, bounded speed, and round-trip time to a distant ad exchange or DSP partner is a floor no amount of hardware optimization can lower. This is why RTB infrastructure placement is as much about proximity to the exchanges and partners you’re actually trading with as it is about raw server specs. A well-tuned bare metal deployment sitting far from your trading partners will still lose auctions to network distance alone, no matter how fast the box itself is.

What This Doesn’t Solve

Dedicated hardware removes infrastructure-introduced latency variance. It doesn’t rewrite your bidding algorithm, doesn’t reduce the number of DSPs you’re evaluating per auction, and doesn’t shrink the physical distance between you and a trading partner on another continent. If your current bottleneck is bidding logic efficiency rather than infrastructure jitter, that’s a software problem no amount of dedicated hardware fixes on its own. And RTB platforms typically generate serious, sustained bandwidth volume across a high request rate; that’s a related but separate cost consideration from latency, covered in more general terms in our breakdown of high-bandwidth use cases on private cloud.

Who This Fits

• Fits well if your platform runs its own bidding logic against a hard auction timeout and infrastructure-side latency variance is a measurable, known problem
• Fits well if you’ve traced missed auctions or inconsistent bid-response times back to noisy-neighbor contention or virtualization overhead on shared cloud infrastructure
• Fits well if sustained high request volume and bandwidth costs are a real, ongoing line item you’re trying to make predictable
• Doesn’t fit as well if your current constraint is bidding algorithm efficiency rather than infrastructure latency, since that’s a software problem infrastructure changes won’t solve
• Doesn’t fit as well if your trading partners and exchanges are geographically distant from every location you’d realistically deploy to, since no infrastructure choice removes the physics of that distance

Getting Started

Dedicated bare metal servers with full root access and no shared hypervisor layer are on our bare metal pricing page, across data centers in Ashburn, Los Angeles, Amsterdam, and Singapore.

FAQ

How much time does a real-time bidding auction actually allow?

The OpenRTB specification’s tmax field defines this per-exchange rather than mandating a fixed number, but independent industry documentation and measurements consistently place the practical window between 80 and 120 milliseconds.

What happens if a bid arrives after the auction timeout?

It’s excluded from the auction entirely. A late bid isn’t discounted or deprioritized, it simply isn’t considered, regardless of how competitive it would have been.

Does dedicated bare metal actually make a measurable difference for RTB latency?

It removes specific, identifiable sources of latency variance, hypervisor overhead and noisy-neighbor contention from other tenants, that exist by default on shared cloud infrastructure. It doesn’t address network distance to trading partners or the efficiency of your own bidding algorithm, which are separate factors.

Why does geographic location matter as much as server hardware for RTB infrastructure?

Network round-trip time to ad exchanges and DSP partners is bounded by the physical speed of light in fiber, a floor that hardware improvements can’t lower. Infrastructure placed far from your actual trading partners will lose auctions to distance regardless of how fast the underlying servers are.