As of late, I’ve been writing about why agentic buys and sells (and direct buys and sells in general) are not the future of programmatic. If you’re interested, the posts are here and here.
The real future lies in making the OpenRTB auction meaningfully more effective for buyers and sellers. The cornerstones of this evolution will be improvements to: (1) cost, (2) auction fairness, (3) data/algorithms, and (4) flywheel compression. All four of these components have been moving in the right direction over the past couple years, and in future posts I’ll address the latter three. Here I want to focus on cost reduction. Specifically, why publishers are going to be making SIGNIFICANTLY more money in the next year thanks to decreasing costs, and how this change will trigger a cascade of second and third-order consequences for the rest of the programmatic ecosystem.
Programmatic systems are notoriously expensive to operate. Depending on the path, a shocking amount of an advertisers’ clearing cost is consumed by fees, reselling, and operational overhead, (often 40-90% GONE!) before the creative ever reaches the publisher. While some of this cost stems from the opacity of vendors (relating to the fairness component), the majority of depleted margin is due to an underlying tech stack that is costly to build and operate at scale.
This cost structure is about to change for two reasons: (1) AI is driving increasing developer productivity; and (2) AWS RTB Fabric is fundamentally altering the economics of bid traffic. I’m going to skip the dev productivity debate because many other developers have wrote about it at length. Instead, I will focus on RTB Fabric – what it actually is, why it matters, and most importantly, how it affects the ad tech ecosystems’ players in aggregate (hint, really really good for pubs!).
RTB Fabric is a managed network service specifically designed for real-time bidding communications between ad tech companies. It is not the bidding engine or the exchange platform; it’s the connective tissue that routes RTB requests and responses between players in a more predictable way than the public internet. The biggest difference between RTB Fabric and existing systems that route RTB traffic is CONSISTENCY.
In RTB, average latency – the time it takes to receive a bid response from a bid request – is not the enemy, tail latency is. It may be possible for your system to route a majority of requests/responses efficiently, but if 1% of your traffic occasionally spikes, you drop bids and miss auctions. This 1% (or any amount of long tail disruption) of delayed traffic leads to problems with downstream requests/responses, ultimately causing a backup of bid requests/responses that will either never get sent to the ad server or never get filled, respectively. In addition to these missed monetization opportunities, any algorithms or models that are trained on the traffic the system can handle will be misrepresentative. Existing sophisticated networking architecture between real time bidding players in the space accounts for some of these variations, but they still lose massive volume to high tail latency. RTB Fabric purports to deliver consistent single-digit millisecond performance for these workloads, preventing almost all drops (have not self-verified yet) and backups caused by said drops.
Will, how can I trust you… can you explain a little bit more about how it works?
Yes! The efficiency comes from two main components that AWS developed in their high-performance computing org, which have been repurposed for ad tech in the form of RTB Fabric: the Nitro System and the Scalable Reliable Datagram (SRD).
To understand why RTB Fabric is faster, we need to first understand how traditional internet traffic works. Traditional internet traffic relies on TCP, which is built for the “public” web. TCP is like a single-lane highway. If a single car (a “packet” in the case of ad tech, which you can think about as a single bid request) breaks down, the entire lane stops until it’s cleared. This process is called “Head-of-Line Blocking.” If one packet is dropped or delayed, the whole bid request hangs, causing the tail latency spike that disrupts the whole bid stream.
AWS RTB Fabric replaces system this with SRD, which works more like a 64-lane superhighway:
- Packet Spraying: Instead of sending all data down one path, SRD “sprays” packets across up to 64 parallel paths simultaneously. If one path is congested, the others keep moving. https://www.ernestchiang.com/en/notes/general/aws-srd-scalable-reliable-datagram/#:~:text=SRD%20adopts%20packet%20spraying%20strategy,9%20static%20load%20balancing%20concepts.
- Hardware Offloading (The Nitro Chip): In a standard setup, your server’s CPU has to stop doing “bidder work” to handle “networking work.” AWS offloads the entire SRD protocol onto a dedicated physical chip called the Nitro Card. Because the networking logic is sitting in hardware – literally millimeters away from the fiber – it can detect a dropped packet and retransmit it in microseconds, long before your software even knows there was a problem.
- Out-of-Order Delivery: TCP wastes time making sure packets arrive in the exact order they were sent. SRD doesn’t care. It delivers packets as fast as possible and reassembles them at the destination hardware. For the “lots of small messages” workload of OpenRTB, this reassembly component is a massive win.
By moving the load balancing and packet recovery from “software trying its best” to “hardware designed for this,” AWS removes the noise of the public internet. This design makes costs more predictable, allowing Amazon to charge in bulk per request.
Because RTB Fabric is more efficient and effective, AWS charges significantly less for processing bid requests here than they do using the traditional cloud setup. Here is the pricing table from Amazon’s website:
Across the board we are seeing reduced pricing by about 6-10x for: (1) the number of bid requests/bid responses processed, and (2) the size of the data transferred in each packet! In addition to lower prices, the system will be able to process MORE bid requests that would’ve previously been lost due to latency spikes. So, WHAT DOES THIS MEAN FOR PUBLISHERS AND ADVERTISERS?
Will publishers now have 6-10x less margin taken from each ad space sale? Will advertisers pay 6-10x less per fulfilled bid request?
My thesis: Publishers will emerge as the primary beneficiaries through a combination of margin recovery and increased fill rates. While existing SSPs, DSPs, ad exchanges and vendors may attempt to absorb these savings in the short term to bolster their own margins, the “ad tech tax” imposed by these intermediaries will face unprecedented deflation.
Historically, the compute and complexity required to build the connectivity layer has created a barrier to enter for new firms. AWS RTB Fabric effectively commoditizes that “glue code.” By lowering the technical floor, we invite a new wave of lean players who, unburdened by legacy technical debt and empowered by AI-driven development, can operate at a fraction of the cost of incumbents. As these new entrants compete on price, market forces will push that recovered margin back toward the publisher. We have already seen this happening in the market in real time. Amazon’s DSP has only been charging 1-3% margin of advertiser cost for the past year! They have been utilizing RTB fabric internally for a while and have made their DSP significantly more competitive by charging the cheapest DSP margins in the industry.
If RTB Fabric delivers on its promise, the era of “structural rent-taking” is over. For a decade, a segment of the ecosystem has extracted value simply by navigating the friction of the open web. When the pipes become cheap, consistent, and commoditized, the moat of connectivity vanishes.
Value will migrate upstream to where it actually compounds: predictive modeling, intelligent load balancing, measurement, essential data providers, and Identity propagation. In a world where plumbing is a utility, the winners will be those who make the best decisions about the data flowing through it, not those who manage the flow.
This shift also solves a psychological hurdle for the industry. The enduring justification for IO-driven “direct” deals (once manual, now agentic) has often been a practical one: the open market felt too lossy and unpredictable. This unpredictability starts to dissipate once margins become lower and more transparent. It also becomes more fair. If supply starts to funnel through the cheapest and most effective paths, underhanded exchanges between intermediaries that exploit publishers/brands will cease to exist. Once the chain is transparent and generates more revenue in most/all cases the argument for manual workflows collapses. OpenRTB, powered by consistent hardware-level performance, finally becomes the default execution layer for all relationships.
We don’t need to abandon the OpenRTB auction for agentic alternatives; we need to continue to improve the auction system we have. By decreasing costs through innovations like RTB Fabric, we set the stage for the next three pillars of evolution: fairness, data efficacy, and flywheel compression.
What do y’all think? Will RTB fabric become widely adopted? Will the incumbents adapt quickly and use existing domain knowledge and large data stores to widen their lead? I don’t think so, but curious if others do and why. In my upcoming posts I will be addressing the other 3 components of this evolution.