At a glance:
- A vendor's first answer on latency should lead with p99, not the average.
- Whether a platform runs on hyperscaler compute or dedicated bare metal changes what "handling a surge" means, and a good vendor explains that tradeoff.
- Real cost modeling means running actual per-GB data movement rates against your traffic, not handing you a rate card and leaving the math to you.
- Support quality shows up in who picks up a 1am latency incident and what they investigate first, not in SLA response-time language.
- Single-tenant isolation and migration risk are the two questions most likely to expose a vendor applying general-purpose playbooks to a bidding stack that doesn't tolerate them.
Eight questions that separate infrastructure vendors who understand real-time bidding from those who don't
Ask a vendor these eight questions and you'll know whether they've run RTB infrastructure or are reading from a general cloud pitch deck.
1. "What p99 latency does the platform guarantee under sustained auction load?"
A good answer leads with p99, not the average, since tail latency determines auction timeout compliance. A vendor without real RTB experience quotes a p50 benchmark and can't explain how it holds up after hours of sustained load, not just in a controlled test.
2. "How does the platform perform when a surge exceeds provisioned capacity?"
On hyperscaler compute, the honest answer covers auto-scaling warm-up: AWS EC2 defaults to 300 seconds, or about 30 with warm pools pre-initialized, during which existing nodes run hot and p99 degrades. On bare metal, the question shifts to whether the pre-provisioned buffer is large enough, since there's no warm-up gap to manage.
3. "What happens to p99 when a neighboring workload on the same physical hardware spikes?"
This only applies to shared compute; a bare metal vendor will say so outright. A hyperscaler vendor should explain the noisy neighbor effect directly, since co-tenant contention at the VM layer affects p99 in ways the platform team can't see or fix. Be wary of any answer that denies this matters or redirects to average latency.
4. "How is data egress and inter-region traffic priced, and what does that look like at 100,000 bids per second?"
This surfaces the gap between the compute invoice and the real cost: NAT Gateway processing runs $0.045/GB, inter-AZ transfer adds $0.01/GB each direction, and at high bid volumes neither is a rounding error. A useful answer applies those rates to your traffic and gives you a number, not a rate card to do the math on yourself.
5. "What does support look like when p99 spikes during a live auction at 1am?"
This isn't about SLA wording. It's about who picks up a 1am incident, what context they bring, and how fast someone with RTB domain knowledge gets involved. Real adtech support names a specific escalation path and what they'd check first; general infrastructure support just describes tiered response times.
6. "What does single-tenant isolation look like in practice, and what does it mean for bidstream data handling?"
Bidstream isolation matters for two reasons: competitive separation between demand partners, and compliance audits that require proof of it. The answer that matters names the physical and network-layer mechanism and says exactly what doesn't cross between tenants, not just which certifications the vendor holds.
7. "What's the full cost of operating this platform at our target bid volume, including support, data movement, and any per-request fees?"
A good answer walks through every billable component at your target volume, compute, storage, data movement, support tier, modeled at that volume rather than handed to you as per-unit rates. If the answer keeps coming back to "it depends" past base compute costs, the cost model probably hasn't been built.
8. "What does migration from our current hyperscaler setup look like, and what's the revenue risk during the transition?"
The honest answer includes a phased approach, a parallel-running period to validate performance before cutover, and a real risk window, not a standard infrastructure timeline. A vendor who's done this knows which pieces of the stack can move without revenue risk, which need a specific order, and which aren't worth moving at all because the engineering lift outweighs the payoff. If a workload would take six to twelve months of engineering time just to break even, the right call might be leaving it on your hyperscaler provider. The giveaway: whether auction continuity and the real cost of the move drive the plan, or get figured out along the way.
These eight questions don’t have a single right answer that fits every workload. What they have in common is that a vendor who's run RTB infrastructure can answer all eight without stalling, and one who hasn't will start improvising by question three.
