RTB Architecture
RTB bidder architecture: real-time bidding system design, component by component
Published · Last updated
Next scheduled review:
A real-time bidding (RTB) bidder is the part of a demand-side platform that answers bid requests inside the exchange's deadline. Good real-time bidding system design splits it into a hot path that decides in milliseconds and a warm path that logs, paces and reports. This page maps each component, its latency budget and the data store behind it.
Contents
Key facts
- The exchange owns the clock. OpenRTB 2.6 defines
tmaxas the "maximum time in milliseconds the exchange allows for bids to be received including Internet latency" (IAB Tech Lab, OpenRTB 2.6). Google's deadline "typically ranges from 80 to 1000 ms" and it throttles bidders that cannot get 85 percent of responses back in time (Google Authorized Buyers, updated 17 September 2026). - Custom decision logic gets about 10 ms. FreeWheel's Beeswax platform gives a customer's bidding agent "a strict timeout of 10ms" for its HTTP response (FreeWheel docs, accessed 9 November 2026).
- Profile stores run at tens of millions of operations a second. AWS reports The Trade Desk writing up to 32 million key-value pairs a second on Aerospike clusters of more than 150 instances (company claim) (AWS for Industries, 10 November 2021).
- An independent full-stack platform still sees about a million requests a second. Adform's infrastructure must process 900,000 to 1.8 million bid requests a second and more than 11 million database operations a second, according to its database vendor (company claim) (Aerospike, Adform story, 11 February 2025).
- Clouds now sell RTB networking as a product. AWS RTB Fabric became generally available on 23 October 2025, promising "single-digit millisecond latency" between ad tech partners (company claim) (AWS, 23 October 2025).
Definition
RTB bidder: the low-latency service inside a demand-side platform that receives each OpenRTB bid request, decides whether and at what price to bid, and answers before the exchange's deadline. It also emits the events that downstream systems use for budgets, frequency and reporting.
The bidder is one service inside a demand-side platform (DSP). It speaks OpenRTB, and each bid request carries its own deadline in the tmax field. If you want the auction itself explained first, read how real-time bidding works. If you are deciding whether to build a DSP at all, with team, cost and timeline, read how to build a DSP platform. This page sits in the RTB architecture hub and covers only what happens inside the bidder.
DSP architecture diagram: the full bidder on one page
A bidder has three planes. The hot path handles one request at a time and must finish inside the deadline. The event pipeline records what happened and feeds the numbers back. The control plane changes what the hot path believes: campaigns, budgets, models and blocklists.
The arrows that point up matter most. Frequency counts, budget allowances, campaign changes and new models all travel from slow systems into fast memory. A bidder is only as current as those refresh loops.
The components and the time each one gets
The table lists every component in the diagram with the most specific public latency figure we could find. Vendor figures are company claims. Where nobody publishes a number, the cell says n/d and the last column gives our design rule instead.
11 of 11 rows
Exchange deadline ( | Sets the total budget, network included | 80 to 1,000 ms at Google; 85% of responses must arrive in time; at most 2% late per location during testing | Google peering guide and test guide, both updated 17 Sep 2026 | Design for the shortest deadline you accept, not the average |
Network to and from the exchange | Carries request and response | "Single-digit millisecond" between partners on AWS RTB Fabric (company claim); TripleLift reported 15 to 20% lower latency on it (company claim) | Run bidders near each trading location; Google recommends peering for high volumes | |
Edge and load balancer | TLS, rate limiting, pre-filtering | n/d; RTB Fabric runs Rate Limiter and OpenRTB Filter modules inline (company claim) | Reject unwanted traffic here, before it costs bidder CPU | |
Bid handler, end to end | Parse, filter, match, price, respond | 20 to 30 ms target in a published DSP reference design; 50 to 150 ms with p99 under 200 ms in a vendor guide | Budget internal time as | |
Campaign index | Find campaigns eligible for this impression | n/d | n/d | In memory in every pod; no network call |
User profile store | Segments, frequency counts, IDs | All lookups in "no more than ten or so milliseconds" (company claim); sub-millisecond server-side in a 20-node benchmark (company benchmark) | One batched read per request, same region, hard timeout | |
Model or custom bidding logic | Predict value, set price | 10 ms strict timeout for a Beeswax bidding agent, HTTP round trip included | Precompute what you can; fall back to a rule price on timeout | |
Budget and pacing gate | Stop overspend, spread delivery | n/d; Beeswax applies budget and pacing as filters inside its bidder | Local allowance check only; refresh asynchronously | |
Win, billing and loss notices | Confirm wins, apply spend, learn from losses | Outside the deadline by design | Idempotent handlers; never block the bid path | |
Event stream | Durable record of every event | Adform cut reporting delay "from 4 hours to seconds" using Aerospike with Kafka (company claim) | Async producer with a local buffer | |
OLAP and reporting | Aggregates for dashboards and API | Druid: query latencies "from the sub-second to a few seconds" (project documentation) | Pre-aggregate by hour; keep raw events in the lake |
Exchange deadline (tmax)
- Job
Sets the total budget, network included
- Published latency figure
80 to 1,000 ms at Google; 85% of responses must arrive in time; at most 2% late per location during testing
- Source and date
Google peering guide and test guide, both updated 17 Sep 2026
- Design rule
Design for the shortest deadline you accept, not the average
Network to and from the exchange
- Job
Carries request and response
- Published latency figure
"Single-digit millisecond" between partners on AWS RTB Fabric (company claim); TripleLift reported 15 to 20% lower latency on it (company claim)
- Source and date
- Design rule
Run bidders near each trading location; Google recommends peering for high volumes
Edge and load balancer
- Job
TLS, rate limiting, pre-filtering
- Published latency figure
n/d; RTB Fabric runs Rate Limiter and OpenRTB Filter modules inline (company claim)
- Source and date
- Design rule
Reject unwanted traffic here, before it costs bidder CPU
Bid handler, end to end
- Job
Parse, filter, match, price, respond
- Published latency figure
20 to 30 ms target in a published DSP reference design; 50 to 150 ms with p99 under 200 ms in a vendor guide
- Source and date
- Design rule
Budget internal time as
tmaxminus network minus a safety margin
Campaign index
- Job
Find campaigns eligible for this impression
- Published latency figure
n/d
- Source and date
n/d
- Design rule
In memory in every pod; no network call
User profile store
- Job
Segments, frequency counts, IDs
- Published latency figure
All lookups in "no more than ten or so milliseconds" (company claim); sub-millisecond server-side in a 20-node benchmark (company benchmark)
- Source and date
- Design rule
One batched read per request, same region, hard timeout
Model or custom bidding logic
- Job
Predict value, set price
- Published latency figure
10 ms strict timeout for a Beeswax bidding agent, HTTP round trip included
- Source and date
- Design rule
Precompute what you can; fall back to a rule price on timeout
Budget and pacing gate
- Job
Stop overspend, spread delivery
- Published latency figure
n/d; Beeswax applies budget and pacing as filters inside its bidder
- Source and date
- Design rule
Local allowance check only; refresh asynchronously
Win, billing and loss notices
- Job
Confirm wins, apply spend, learn from losses
- Published latency figure
Outside the deadline by design
- Source and date
- Design rule
Idempotent handlers; never block the bid path
Event stream
- Job
Durable record of every event
- Published latency figure
Adform cut reporting delay "from 4 hours to seconds" using Aerospike with Kafka (company claim)
- Source and date
- Design rule
Async producer with a local buffer
OLAP and reporting
- Job
Aggregates for dashboards and API
- Published latency figure
Druid: query latencies "from the sub-second to a few seconds" (project documentation)
- Source and date
- Design rule
Pre-aggregate by hour; keep raw events in the lake
Table by AdSovereign, CC BY 4.0.
Two numbers frame the rest. The exchange's deadline is often generous, but a bidder in the wrong region spends most of it on the wire. And the parts that need data, the profile lookup and the model, get about 10 ms each in the figures published by Aerospike and FreeWheel. Everything else on the hot path is a memory lookup.
Edge and load balancer
The edge terminates TLS (the encryption on each connection), spreads traffic across bidder pods and throws away what you cannot use. Exchanges send more than any DSP wants. Index Exchange estimates about 10 million queries per second (QPS) across the internet and says each DSP caps its intake at something like 1 to 3 million (Index Exchange, accessed 9 November 2026). Every request you accept costs CPU and bandwidth whether you bid or not.
A pre-filter at the edge drops requests for formats, countries or sellers that no live campaign wants. It is the cheapest optimisation in the system. The same idea now runs on the seller's side too. The Dynamic Traffic Engine lets a buyer publish filtering signals that the supply-side platform (SSP) checks before sending a request (IABTechLab/DynamicTrafficEngine, accessed 9 November 2026). Amazon Ads donated it to IAB Tech Lab on 15 April 2026 (IAB Tech Lab, 15 April 2026).
Bid handler and campaign index
The bid handler is a stateless service. It parses the OpenRTB 2.6 request, reads consent, checks the request against blocklists and then asks one question: which live campaigns want this impression? The answer comes from a campaign index held in memory in every pod. A typical index is an inverted map from targeting values (country, format, deal ID, segment) to campaign IDs, rebuilt by a separate job and pushed to pods every few seconds.
Stateless pods make scaling simple. You add pods behind the load balancer when QPS grows and remove them when it falls. The AWS reference bidder follows this pattern on Kubernetes and Graviton instances. It keeps device and campaign data in DynamoDB or Aerospike and sends events through Kinesis (AWS Solutions Library, guidance repository, accessed 9 November 2026). Its example load test uses a 100 ms timeout.
User profile store
Targeting and frequency capping need per-user state: segments, recent exposures, a match between the exchange's ID and yours. That state is too big for pod memory and too hot for a normal database. Aerospike's own guidance says all profile retrieval should happen "in no more than ten or so milliseconds", often with "dozens of individual data retrievals" inside that window (Aerospike, 2 July 2024).
The practical rule is one batched read per request, keyed by every user ID the request carries, with a hard timeout. If the read times out, the bidder either skips user targeting or returns no bid. It must not wait.
Model serving and pricing
Pricing has two steps. A model predicts what the impression is worth to the campaign, for example the probability of a click or a conversion. A second step decides how far below that value to bid in a first-price auction; that step is covered in bid shading explained.
Beeswax's 10 ms limit for a whole external bidding agent is a useful ceiling (FreeWheel docs, accessed 9 November 2026). Models that need more time run in the warm path and publish lookup tables or compact models that the hot path can evaluate in microseconds. Load new model versions behind a flag and compare their bids with the old version on a small share of traffic first.
Budget and pacing
A campaign with a fixed daily budget, served by hundreds of bidder pods, has a coordination problem. No pod can ask a central ledger before each bid. The common answer is a local allowance: each pod gets a small slice of the remaining budget, spends against it in memory and asks for more on a short timer. A pacing controller adjusts how often the campaign bids so that spend follows a curve through the day.
This is an old, studied problem. Yahoo researchers described a "smart pacing" method that learns each campaign's delivery pace from offline and online data, implemented "in a real DSP system" (Xu et al., arXiv, 18 June 2015; KDD 2015). Beeswax exposes the same idea as a filter: its "Pacing-as-a-Service" removes bids "based on the ratio of current delivery against goals" (FreeWheel docs, accessed 9 November 2026). Accept that allowances can overshoot slightly between refreshes, and size the slices so the worst case stays inside your tolerance.
Win, billing and loss notices
OpenRTB separates three signals. The win notice (nurl) says you won the auction. The billing notice (burl) says the impression became billable. The spec puts it plainly: "The win notice informs the bidder's pricing algorithms of a success, whereas the billing notice indicates that spend should actually be applied" (IAB Tech Lab, OpenRTB 2.6). The loss notification (lurl) tells you why you lost; release 2.6 added the ${AUCTION_MIN_TO_WIN} macro, which OpenRTB 2.6 explained walks through.
Decrement budgets on the billing notice, not the win notice. Make every notice handler idempotent, because exchanges retry and networks duplicate.
Event pipeline and reporting
Every bid, no-bid, win, billable impression, loss, click and conversion becomes an event. The bidder writes events to a local buffer and a background producer ships them to a stream such as Apache Kafka or Amazon Kinesis Data Streams. Consumers then update the budget ledger, write frequency counts back to the profile store and check for fraud.
Raw events land in object storage as Parquet files partitioned by hour. An online analytical processing (OLAP) store such as Apache Druid or ClickHouse serves the dashboards. Apache Druid lists digital advertising analytics among its main use cases. Its documentation describes ingesting "millions of records per second" with query latencies "from the sub-second to a few seconds" (Apache Druid docs, accessed 9 November 2026). The same raw events are what buyers ask for when they request log-level data.
A worked latency budget for a 120 ms deadline
The video example in the OpenRTB 2.6 specification uses "tmax": 120 (IAB Tech Lab, OpenRTB 2.6, section 6.2.4). The configuration below splits that deadline into stage budgets. The stage values are our assumptions, chosen to fit the published 10 ms figures for the profile store and the model; replace them with your own measurements.
{
"exchange": "exchange-a.example",
"tmax_ms": 120,
"network_round_trip_budget_ms": 30,
"safety_margin_ms": 15,
"internal_deadline_ms": 75,
"stages": [
{ "name": "parse_and_prefilter", "budget_ms": 3, "on_timeout": "no_bid" },
{ "name": "campaign_match", "budget_ms": 5, "on_timeout": "no_bid" },
{ "name": "user_profile_lookup", "budget_ms": 10, "on_timeout": "continue_without_profile" },
{ "name": "model_score", "budget_ms": 10, "on_timeout": "use_rule_price" },
{ "name": "budget_and_pacing_gate", "budget_ms": 1, "on_timeout": "no_bid" },
{ "name": "build_response", "budget_ms": 2, "on_timeout": "no_bid" }
],
"on_internal_deadline": "return_http_204"
}7 of 7 rows
| The exchange's deadline, read from each request | The spec says it "supersedes any a priori guidance from the exchange" |
| Time reserved for the request and response on the wire | Assumption; measure it per exchange and region |
| Slack for garbage collection pauses and queueing | Google advises "targeting a total time well below the deadline" |
| 120 minus 30 minus 15 | The bidder stops work at this point |
| Per-stage budgets that sum to 31 ms | The remaining 44 ms absorbs queueing under load |
| What each stage does when it runs out of time | A late bid earns nothing, so degrade rather than wait |
| Return HTTP 204, the cheapest no-bid | OpenRTB recommends 204 for "no content" responses |
tmax_ms
- What it does
The exchange's deadline, read from each request
- Why
The spec says it "supersedes any a priori guidance from the exchange"
network_round_trip_budget_ms
- What it does
Time reserved for the request and response on the wire
- Why
Assumption; measure it per exchange and region
safety_margin_ms
- What it does
Slack for garbage collection pauses and queueing
- Why
Google advises "targeting a total time well below the deadline"
internal_deadline_ms
- What it does
120 minus 30 minus 15
- Why
The bidder stops work at this point
stages
- What it does
Per-stage budgets that sum to 31 ms
- Why
The remaining 44 ms absorbs queueing under load
on_timeout
- What it does
What each stage does when it runs out of time
- Why
A late bid earns nothing, so degrade rather than wait
on_internal_deadline
- What it does
Return HTTP 204, the cheapest no-bid
- Why
OpenRTB recommends 204 for "no content" responses
Table by AdSovereign, CC BY 4.0.
The quotes in the table come from the OpenRTB 2.6 specification and Google's peering guide (IAB Tech Lab, OpenRTB 2.6; Google, updated 17 September 2026). Track p99 latency per stage and per exchange, not the average. A mean of 20 ms can hide a tail that misses the deadline on one request in fifty. Turning a QPS target into hardware is the job of the bidder capacity planner, and the planned RTB latency calculator will automate this split.
Why Aerospike shows up in ad tech: choosing the data stores
Each kind of data in a bidder has a different access pattern, so mature stacks use several stores. The table matches each one to the stores teams commonly choose. Versions link to each project's release page, checked on the day of the last update above.
7 of 7 rows
Campaigns, line items, creatives | Read on every request; changes every few seconds | In-process index built from a relational database | No network hop on the hot path |
User profiles and segments | Point reads at full QPS; bulk writes from batch jobs | Aerospike (8.2.0.1, 28 Oct 2026); Amazon DynamoDB | Predictable low latency on flash at billions of keys |
Frequency counters | Read and increment per impression, expire after a window | Redis (8.10.3, 26 Oct 2026) or the profile store itself | Atomic increments with time-to-live |
Event stream | Append-only, very high write rate, replayable | Apache Kafka (4.4.0); Amazon Kinesis Data Streams | Decouples the bidder from slow consumers |
Raw event archive | Write once, scan for analytics and audits | Amazon S3 or another object store, Parquet files | Cheap, columnar, partitioned by hour |
Reporting aggregates | Sub-second slice-and-dice for dashboards | Apache Druid (38.0.0, 1 Oct 2026); ClickHouse (26.10, 24 Oct 2026) | Columnar storage with time partitioning |
Budget ledger | Exact totals per campaign, many concurrent writers | Relational database fed by the event stream | Money needs consistency, not microseconds |
Campaigns, line items, creatives
- Access pattern
Read on every request; changes every few seconds
- Common choices (latest release)
In-process index built from a relational database
- Why this choice
No network hop on the hot path
User profiles and segments
- Access pattern
Point reads at full QPS; bulk writes from batch jobs
- Common choices (latest release)
Aerospike (8.2.0.1, 28 Oct 2026); Amazon DynamoDB
- Why this choice
Predictable low latency on flash at billions of keys
Frequency counters
- Access pattern
Read and increment per impression, expire after a window
- Common choices (latest release)
Redis (8.10.3, 26 Oct 2026) or the profile store itself
- Why this choice
Atomic increments with time-to-live
Event stream
- Access pattern
Append-only, very high write rate, replayable
- Common choices (latest release)
Apache Kafka (4.4.0); Amazon Kinesis Data Streams
- Why this choice
Decouples the bidder from slow consumers
Raw event archive
- Access pattern
Write once, scan for analytics and audits
- Common choices (latest release)
Amazon S3 or another object store, Parquet files
- Why this choice
Cheap, columnar, partitioned by hour
Reporting aggregates
- Access pattern
Sub-second slice-and-dice for dashboards
- Common choices (latest release)
Apache Druid (38.0.0, 1 Oct 2026); ClickHouse (26.10, 24 Oct 2026)
- Why this choice
Columnar storage with time partitioning
Budget ledger
- Access pattern
Exact totals per campaign, many concurrent writers
- Common choices (latest release)
Relational database fed by the event stream
- Why this choice
Money needs consistency, not microseconds
Table by AdSovereign, CC BY 4.0.
Aerospike appears in so many ad tech stacks because profile stores are large and read-heavy. In a 2021 benchmark run with AWS and Intel, a 20-node Aerospike cluster held 500 TB of compressed profile data. It served more than 5 million read-only transactions a second with sub-millisecond server-side latency (company benchmark) (AWS for Industries, 10 November 2021). Adform moved from Cassandra and SQL Server to Aerospike and reports going from 32-node Cassandra clusters to 3-node Aerospike clusters per data centre (company claim) (Aerospike, 11 February 2025).
Redis is the usual choice when the dataset fits in memory and the job is counters, caches or rate limits. DynamoDB trades some latency control for zero operations work, which is why AWS offers it as one of two stores in its reference bidder. None of these stores belongs on the hot path for money. Budgets live in a ledger that tolerates seconds of delay; the hot path sees only allowances.
Scaling the bidder: regions, QPS and traffic shaping
A bidder scales out, not up. Stateless bid handler pods sit behind a regional load balancer, one cluster per trading region. Google tries to send each request to the trading location closest to the user. It warns that "to receive all impressions, you need to have servers reachable from all locations" (Google Authorized Buyers, updated 17 September 2026). In practice that means a cluster on each US coast, one in Europe and one in Asia for a global buyer.
Network cost and distance push bidders toward the exchanges. Back in 2014, Google gave bidders hosted on Compute Engine "100 milliseconds for bid request processing" and free transit to its trading locations (Google Cloud Platform Blog, 19 March 2014).
AWS RTB Fabric is the current version of that idea: private links between partners, inline filtering modules and pricing per billion transactions instead of per gigabyte (PPC Land, 23 October 2025). Axel Springer, the publisher of BILD and POLITICO, became the first publisher to adopt it after moving to a self-hosted Prebid Server, according to AWS (AWS for Industries, 21 July 2026).
Traffic you never receive is the cheapest to process. Agree QPS caps per exchange, filter at the edge and use seller-side shaping such as the Dynamic Traffic Engine where your partners support it. Duplication makes this urgent: The Trade Desk's Will Doherty has described SSPs that send the same publisher traffic "three times" (AdExchanger, 17 January 2024). The commercial side of QPS limits is covered in QPS, latency and bid performance, and node sizing tiers in self-hosted DSP infrastructure requirements.
Failure modes and how a bidder should degrade
A bidder that fails slowly is worse than one that fails fast. A slow bidder misses deadlines, gets throttled and loses traffic for minutes. Google says a bidder with high timeout rates "will be automatically throttled", and that traffic recovers "over a time-frame of a few minutes" (Google Authorized Buyers test guide, updated 17 September 2026).
7 of 7 rows
Profile store slow or partitioned | p99 jumps; timeouts rise; exchange throttles you | Hard read timeout; bid without profile or return 204; per-store circuit breaker |
Model server slow after a deploy | Bid prices drift or time out | Fallback rule price; canary new models on a small traffic share |
Campaign index stale | Bids on paused campaigns or blocked sellers | Version every snapshot; refuse to bid if the snapshot is older than a set age |
Budget allowance overshoot | Spend above the daily cap | Small allowance slices; hard stop at ledger level; reconcile against billing notices |
Event stream backlog | Reports and frequency counts lag | Local buffer with back-pressure; alert on consumer lag; never block the bid path |
Duplicate requests for one impression | Bidding against yourself; inflated QPS | Deduplicate on |
Whole cloud region down | Traffic from that trading location lost | Multi-region deployment; health-checked DNS; replicated profile store |
Profile store slow or partitioned
- What you see
p99 jumps; timeouts rise; exchange throttles you
- Mitigation
Hard read timeout; bid without profile or return 204; per-store circuit breaker
Model server slow after a deploy
- What you see
Bid prices drift or time out
- Mitigation
Fallback rule price; canary new models on a small traffic share
Campaign index stale
- What you see
Bids on paused campaigns or blocked sellers
- Mitigation
Version every snapshot; refuse to bid if the snapshot is older than a set age
Budget allowance overshoot
- What you see
Spend above the daily cap
- Mitigation
Small allowance slices; hard stop at ledger level; reconcile against billing notices
Event stream backlog
- What you see
Reports and frequency counts lag
- Mitigation
Local buffer with back-pressure; alert on consumer lag; never block the bid path
Duplicate requests for one impression
- What you see
Bidding against yourself; inflated QPS
- Mitigation
Deduplicate on
source.tidand impression ID within a short window
Whole cloud region down
- What you see
Traffic from that trading location lost
- Mitigation
Multi-region deployment; health-checked DNS; replicated profile store
Table by AdSovereign, CC BY 4.0.
The last row is not theoretical. AdExchanger reported an AWS outage of more than 12 hours, attributed to a DNS error in a US data centre, in the same week RTB Fabric launched (AdExchanger, 23 October 2025). Every component in the table should have a written degraded mode, and someone should test it before the first live budget.
Published engineering references, with dates
Few DSPs publish their internals. These are the most specific public sources we found, in date order. Figures from vendors about their own products or customers are company claims.
10 of 10 rows
19 Mar 2014 | Cloud-hosted bidders on AdX got 100 ms of processing time and free transit | |
18 Jun 2015 | Budget pacing learned from data, implemented in a production DSP | |
7 Oct 2016, revised 15 Jul 2017 | Academic survey of RTB auctions, bid optimisation and pacing | |
10 Nov 2021 | Aerospike benchmark; The Trade Desk at 32 million writes a second (company claim) | |
26 Jan 2023 (created) | Open-source reference bidder: EKS, DynamoDB or Aerospike, Kinesis | |
5 Oct 2023 | DSP reference design with a 20 to 30 ms response target | |
2 Jul 2024 | Profile lookups within about 10 ms (company claim) | |
11 Feb 2025 | 900,000 to 1.8 million bid requests a second; Kafka plus Aerospike (company claim) | |
23 Oct 2025 | Managed private RTB network with inline modules (company claim) | |
21 Jul 2026 | Self-hosted Prebid Server moved onto RTB Fabric |
19 Mar 2014
- What it shows
Cloud-hosted bidders on AdX got 100 ms of processing time and free transit
18 Jun 2015
- What it shows
Budget pacing learned from data, implemented in a production DSP
7 Oct 2016, revised 15 Jul 2017
- What it shows
Academic survey of RTB auctions, bid optimisation and pacing
10 Nov 2021
- Source
- What it shows
Aerospike benchmark; The Trade Desk at 32 million writes a second (company claim)
26 Jan 2023 (created)
- What it shows
Open-source reference bidder: EKS, DynamoDB or Aerospike, Kinesis
5 Oct 2023
- Source
- What it shows
DSP reference design with a 20 to 30 ms response target
2 Jul 2024
- Source
- What it shows
Profile lookups within about 10 ms (company claim)
11 Feb 2025
- Source
- What it shows
900,000 to 1.8 million bid requests a second; Kafka plus Aerospike (company claim)
23 Oct 2025
- Source
- What it shows
Managed private RTB network with inline modules (company claim)
21 Jul 2026
- What it shows
Self-hosted Prebid Server moved onto RTB Fabric
Table by AdSovereign, CC BY 4.0.
If you are preparing for an ad tech system design interview
The canonical prompt is "Design a real-time bidding system" or "Design the bidder for a DSP". Interviewers want to see that you start from the deadline, separate the hot path from everything else and treat money with care. This eight-step answer fits a typical interview slot.
- Pin the numbers first. Ask for peak QPS, the exchange deadline and the regions. If they give none, use public anchors. Google's deadlines run from 80 to 1,000 ms (Google, updated 17 September 2026), and Index Exchange estimates 1 to 3 million QPS for a large DSP (Index Exchange, accessed 9 November 2026).
- Draw the hot path and give it a budget. Load balancer, stateless bid handlers, in-memory campaign index, profile store, model, pacing gate, response. Write the millisecond budget next to each box, as in the worked example above.
- Choose stores by access pattern. A key-value store for profiles, memory for campaigns, a log for events, columnar storage for reports. Say why each one fits and what you would not put on the hot path.
- Handle budgets with allowances. Explain local allowances, a central ledger fed by billing events, and the overspend you will accept between refreshes.
- Close the loop with notices and events. Win, billing and loss notices go to idempotent endpoints, then into the event stream. Budget decrements on billing, not on winning.
- Scale out and across regions. Stateless pods per region, replicated profile data, QPS caps and edge filtering per exchange.
- Plan for failure. Timeouts on every dependency, fallback prices, circuit breakers, a kill switch per campaign and a rule that a late answer is a 204.
- Prove it works. Per-exchange p99 dashboards, replay of logged requests for load tests, and daily reconciliation of your logs against exchange invoices.
If you have time left, mention bid shading, consent handling and deduplication. Those three topics separate a generic answer from an ad tech one.
Common mistakes
- Calling a remote database on the hot path without a timeout. One slow dependency turns into exchange-wide throttling within minutes.
- Budgeting against the average deadline. Exchanges and formats differ. The shortest
tmaxyou accept sets your design point. - Decrementing budget on the win notice. OpenRTB separates winning from billing. Count spend on
burl, or you will under-deliver on impressions that never render. - Non-idempotent notice handlers. Retries and duplicates are normal. Store notice IDs and ignore repeats.
- Treating QPS as a target. Every request you accept costs money. Filter at the edge and cap per exchange.
- One region for a global buyer. Google tries to route each request to the trading location nearest the user; a single region loses or delays the rest.
- Shipping models without a fallback. A model that times out should produce a rule-based price or a no-bid, not a late bid.
- Reporting from the bidder's memory. Reports must come from the event log, the same records you would hand an auditor, not from counters inside pods.
FAQ
What database do DSPs use for user profiles?
How fast must an RTB bidder respond?
tmax, which includes network time. At Google the deadline typically runs from 80 to 1,000 ms, and 85 percent of responses must arrive in time (Google Authorized Buyers, updated 17 September 2026). Internal processing usually gets a few tens of milliseconds once network and safety margin are taken out.What is the difference between a win notice and a billing notice?
Should a bidder call a machine learning model on every request?
How do you design a real-time bidding system in an interview?
How this works on owned infrastructure
Every box in the diagram above is a place where bid requests, user data and spend records live. When a vendor runs the bidder, the profile store, the event stream and the raw logs sit in the vendor's cloud account, and you see what its reports expose. AdSovereign is an enterprise RTB stack (DSP, SSP, exchange, DMP and clean room) designed to run in your own data centre or cloud account. You then set the regions, the per-exchange QPS caps and the stage timeouts yourself, and the event log that feeds budgets is the same log you can hand to an auditor. The architecture page maps its components to this diagram, and the TCO calculator prices the infrastructure lines.
Sources
- IAB Tech Lab, "OpenRTB API Specification Version 2.6" (2.6.md, main branch; latest release 2.6-202606 of 11 June 2026; accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
- Google for Developers, Authorized Buyers RTB, "Latency Restrictions and Peering" (last updated 17 September 2026). https://developers.google.com/authorized-buyers/rtb/peer-guide
- Google for Developers, Authorized Buyers RTB, "Testing and Releasing Your Application" (last updated 17 September 2026). https://developers.google.com/authorized-buyers/rtb/test-guide
- Google Cloud Platform Blog, "Optimizations to Google Cloud Platform for Real Time Bidding on DoubleClick Ad Exchange" (19 March 2014). https://cloudplatform.googleblog.com/2014/03/optimizations-to-google-cloud-platform-for-real-time-bidding-on-doubleclick-ad-exchange.html
- FreeWheel Advertiser API documentation, "Bidding Agent" (accessed 9 November 2026). https://api-docs.freewheel.tv/advertiser/docs/bidding-agent
- AWS for Industries, "Running Ad Tech Workloads on AWS with Aerospike at Petabyte Scale" (10 November 2021). https://aws.amazon.com/blogs/industries/running-ad-tech-workloads-on-aws-with-aerospike-at-petabyte-scale
- Aerospike, "Adform" customer story (published 11 February 2025, modified 20 May 2026). https://aerospike.com/resources/customer-stories/adform/
- Aerospike, "User profile store for real-time bidding" (2 July 2024). https://aerospike.com/blog/user-profile-store-rtb
- Redpanda, "Build a reference architecture for a demand-side platform in AdTech" (5 October 2023). https://www.redpanda.com/blog/reference-architecture-demand-side-platform-adtech
- Epom, "How to Build Your Own DSP and Is It Even Worth It?" (11 September 2025). https://epom.com/blog/dsp/how-to-build-your-own-dsp
More sources (13)
- AWS Solutions Library, "Guidance for Building a Real Time Bidder for Advertising on AWS" (GitHub, created 26 January 2023, last push 25 November 2025). https://github.com/aws-solutions-library-samples/guidance-for-building-a-real-time-bidder-for-advertising-on-aws
- AWS What's New, "Now generally available: AWS RTB Fabric for real-time bidding workloads" (23 October 2025). https://aws.amazon.com/about-aws/whats-new/2025/10/aws-rtb-fabric-generally-available
- PPC Land, "AWS launches dedicated network for real-time ad bidding workloads" (23 October 2025). https://ppc.land/aws-launches-dedicated-network-for-real-time-ad-bidding-workloads/
- AdExchanger, "AWS launches a cloud infrastructure service for ad tech" (23 October 2025). https://www.adexchanger.com/platforms/aws-launches-a-cloud-infrastructure-service-for-ad-tech
- AWS for Industries, "How Axel Springer transformed ad monetization by migrating from client-side bidding to AWS RTB Fabric" (21 July 2026). https://aws.amazon.com/blogs/industries/how-axel-springer-transformed-ad-monetization-by-migrating-from-client-size-bidding-to-aws-rtb-fabric/
- Index Exchange, "QPS Optimization in Programmatic" (accessed 9 November 2026). https://www.indexexchange.com/index-explains/qps-optimization-programmatic/
- IAB Tech Lab, Dynamic Traffic Engine repository (accessed 9 November 2026). https://github.com/IABTechLab/DynamicTrafficEngine
- IAB Tech Lab, "IAB Tech Lab Announces Dynamic Traffic Engine Donation from Amazon Ads to Improve Bidstream Efficiency" (15 April 2026). https://iabtechlab.com/press-releases/iab-tech-lab-announces-dynamic-traffic-engine-donation-from-amazon-ads/
- AdExchanger, "Attack Of The Clones: Programmatic's Hidden Scourge Of Bid Duplication" (17 January 2024). https://www.adexchanger.com/platforms/attack-of-the-clones-programmatics-hidden-scourge-of-bid-duplication/
- Jian Xu, Kuang-chih Lee, Wentong Li, Hang Qi and Quan Lu, "Smart Pacing for Effective Online Ad Campaign Optimization" (arXiv, 18 June 2015; KDD 2015). https://arxiv.org/abs/1506.05851
- Jun Wang, Weinan Zhang and Shuai Yuan, "Display Advertising with Real-Time Bidding (RTB) and Behavioural Targeting" (arXiv, 7 October 2016, revised 15 July 2017). https://arxiv.org/abs/1610.03013
- Apache Druid, "Introduction to Apache Druid" design documentation (accessed 9 November 2026). https://druid.apache.org/docs/latest/design/
- Release pages read on 9 November 2026: Aerospike Server 8.2.0.1 (28 October 2026), https://github.com/aerospike/aerospike-server/releases; Redis 8.10.3 (26 October 2026), https://github.com/redis/redis/releases; Apache Druid 38.0.0 (1 October 2026), https://github.com/apache/druid/releases; ClickHouse 26.10.2.103-stable (24 October 2026), https://github.com/ClickHouse/ClickHouse/releases; Apache Kafka 4.4.0, https://downloads.apache.org/kafka/