At a Glance
Programmatic advertising runs on one of the most latency-sensitive distributed systems in commercial software, where every bid decision must happen in under 100 milliseconds. Real-time bidding at scale requires specialized data engineering—from in-memory lookups and stateless bidder services to event streaming pipelines and fraud detection systems built for extreme throughput. The competitive edge comes from infrastructure that can make faster, more accurate bidding decisions without sacrificing delivery, pacing, or inventory quality.
Every time a webpage loads, a silent auction takes place in the time it takes to blink. An ad impression becomes available, a bid request is broadcast to dozens of demand-side platforms, each evaluates the opportunity against their targeting criteria and budget constraints, places a bid, and the winner’s creative is returned and rendered — all within 100 milliseconds. Programmatic advertising is one of the most latency-constrained distributed systems in commercial software, and the data engineering behind it is correspondingly demanding.
Understanding what makes RTB infrastructure work — and what makes it break at scale — is essential for any engineering team operating in the programmatic space. The margin for error is measured in milliseconds, and the cost of getting it wrong is measured in lost revenue, wasted spend, and damaged publisher relationships.
The Anatomy of a Bid Request
A bid request travels from a publisher’s ad server to a supply-side platform (SSP), which enriches it with audience data and distributes it to connected demand-side platforms (DSPs). Each DSP has a hard deadline — typically 80 to 100 milliseconds from receipt of the request — to evaluate the impression, look up relevant user data, score the opportunity, calculate a bid price, and return a response. Requests that arrive after the deadline are discarded, regardless of bid value.
Latency reality: A DSP bidder that responds in 120ms instead of 95ms does not win fewer auctions — it wins zero auctions. Latency in RTB is a binary constraint, not a sliding scale.
The data lookups that happen within this window are the core engineering challenge. A bidder needs to know, in real time: whether this user matches any active audience segments, what frequency cap state exists for this user and campaign, what the predicted click or conversion probability is for this impression, and what the optimal bid price is given remaining budget and campaign pacing. Each of these lookups must complete in single-digit milliseconds to leave room for network transit and processing overhead.
The Low-Latency Data Stack
The infrastructure that makes sub-100ms bidding possible is not conventional. Standard relational databases, even well-tuned ones, cannot serve the read throughput that a bidder at scale requires — a large DSP may process hundreds of thousands of bid requests per second at peak. The data stack for RTB has three layers, each selected for latency characteristics rather than general-purpose utility.
In-memory caching is the foundation. User segment memberships, frequency cap counts, and campaign eligibility data are pre-computed and stored in Redis or a similar in-memory store, where lookups complete in under a millisecond. The critical engineering discipline here is cache population: the data in the cache must reflect the most recent segment updates and frequency events, which means the write pipeline that populates it must be both fast and reliable.
- Aerospike is widely used in RTB for user data storage — its hybrid memory architecture (indexes in RAM, data on SSD) offers Redis-like latency at a fraction of the memory cost for large user datasets
- Consistent hashing across cache nodes allows the bidder fleet to route user lookups deterministically, avoiding the cold-start problem when nodes are added or replaced
- Cache warming after a deployment is not optional — a bidder fleet that starts cold under production traffic will miss its latency targets until the cache populates, which can take minutes
The bidding logic itself must be stateless and horizontally scalable. Bidders are typically written in C++, Go, or Rust — languages chosen for predictable latency under load rather than developer ergonomics. JVM-based languages, with their garbage collection pauses, are generally avoided in the hot path. The bid calculation — applying targeting rules, scoring the impression, calculating a price — must be deterministic and fast, with no blocking I/O.
Architecture principle: Separate the read path from the write path entirely. The bidder reads pre-computed data from cache; it never queries a database directly. All updates to targeting, budgets, and frequency caps flow through an asynchronous write pipeline that updates the cache without touching the bidder.
Event Streaming and Auction Analytics
Every bid, win, loss, impression, click, and conversion generates an event. At scale, this event stream is enormous — a large DSP handling 500,000 bid requests per second generates billions of events per day. Making this data useful for campaign optimisation, pacing, and reporting requires a streaming pipeline capable of processing it in near-real time.
Kafka is the standard choice for event ingestion at this scale, with its ability to buffer event spikes, replay historical data for reprocessing, and fan out to multiple consumers. Downstream of Kafka, the processing layer splits into two paths: a real-time path for operational decisions (pacing control, frequency cap updates, budget exhaustion) and an analytical path for reporting and model training.
- Pacing requires second-level granularity — a campaign that is 20% over-paced at the halfway point of the day needs its bid prices adjusted now, not when the next hourly report runs
- Frequency capping at RTB scale requires a distributed counter system with sub-millisecond write latency and eventual consistency guarantees — exact counts at this throughput are computationally impractical
- Win rate and bid landscape data, aggregated from the event stream, feeds the bid optimisation models that set prices — closing the feedback loop between auction outcomes and bidding strategy
Invalid Traffic Detection: The Data Quality Problem
Programmatic advertising has a significant fraud problem. Invalid traffic — bot activity, click farms, domain spoofing, and ad stacking — is estimated to represent a material fraction of all programmatic impressions. For DSPs and advertisers, paying for invalid traffic is a direct financial loss. For SSPs and publishers, failing to filter it damages relationships and triggers financial clawbacks.
IVT detection is a data engineering problem as much as a machine learning one. The features that distinguish invalid from valid traffic — request patterns, device fingerprints, IP reputation, bidstream anomalies — must be computed and applied within the bid evaluation window or in a pre-bid filtering layer. Models trained on historical fraud patterns must be retrained continuously as fraud techniques evolve. And the scoring infrastructure must operate at the same latency targets as the rest of the bidding stack.
The Engineering Discipline That Differentiates
RTB infrastructure is one of the few domains where engineering quality is directly and immediately measurable in business outcomes. A 10ms improvement in bidder p99 latency translates to more auctions entered and more impressions won. A more accurate pacing algorithm translates to less budget waste and better campaign delivery. A more robust IVT filter translates to higher-quality inventory and better advertiser outcomes. In few other engineering domains is the line between technical excellence and commercial performance so direct.
At Nineleaps, we build the low-latency data infrastructure that programmatic advertising demands — from bidder architecture to real-time analytics pipelines that keep pace with the auction.
