System DesignBeginnerarticle

System Design: Designing a Real-time Bidding (RTB) Ad System

How do Google and Facebook run millions of ad auctions in under 100ms? A technical deep dive into DSPs, SSPs, Ad Exchanges, and Low-Latency Infrastructure.

Sachin SarawgiApril 20, 20263 min read3 minute lesson

System Design: Designing a Real-time Bidding (RTB) Ad System

Real-time Bidding (RTB) is the backbone of the modern digital advertising industry. When you load a webpage, an auction happens in the background to decide which ad you see. The entire process—from the moment the page starts loading to the ad appearing—must happen in less than 100 milliseconds.

1. The Core Players

  • The Publisher: The website or app where the ad will appear.
  • SSP (Supply-Side Platform): Represents the publisher and offers their "Ad Impression" for sale.
  • Ad Exchange: The marketplace where the auction happens.
  • DSP (Demand-Side Platform): Represents advertisers and bids on impressions based on user data.

2. The 100ms Race: Step-by-Step

  1. User loads page: The browser pings the Ad Server (SSP).
  2. Auction Starts: The SSP sends an "Auction Request" to the Ad Exchange.
  3. Bidding: The Exchange sends the request to multiple DSPs.
  4. Scoring: Each DSP checks its database: "Who is this user? What is my advertiser willing to pay?"
  5. Bid Response: DSPs send their bids back to the Exchange.
  6. Winner: The Exchange picks the highest bid and notifies the winner.
  7. Rendering: The ad is delivered to the browser.

3. High-Performance Infrastructure

To survive this 100ms window, every microsecond counts.

  • The Database: Traditional SQL or even Redis might be too slow for the heavy profiling DSPs do. Many DSPs use Aerospike or Scallay, which are optimized for ultra-low latency flash storage.
  • Network: Use Global Server Load Balancing (GSLB) to route requests to the nearest data center.
  • Protocol: Use binary protocols like gRPC or Protocol Buffers instead of JSON to reduce serialization overhead.

4. Scaling the DSP: User Profiling

DSPs store massive amounts of data about users (cookies, history, demographics).

  • The Challenge: Millions of user profiles must be accessible in < 5ms.
  • The Solution: Use an In-memory NoSQL store with high throughput and predictable P99 latency.

5. Budget Management and Pacing

An advertiser doesn't want to spend their entire $10,000 daily budget in the first 5 minutes of the morning.

  • Pacing Engine: A distributed service that monitors spending in real-time and slows down bidding if the budget is being consumed too fast.
  • Synchronization: Use a high-speed counter (Redis) to track global spend across all bidding nodes.

6. Fraud Detection

Ad fraud (bots) is a multibillion-dollar problem.

  • The Filter: Use a pre-bid filter (like IAS or DoubleVerify) to detect suspicious IP addresses or user agents before placing a bid.

Summary

The engineering of RTB is the ultimate challenge in Latency vs. Accuracy. By optimizing the network path and using specialized NoSQL databases, you can build a system that runs the world's largest marketplace in the blink of an eye.

📚

Recommended Resources

Designing Data-Intensive ApplicationsBest Seller

The definitive guide to building scalable, reliable distributed systems by Martin Kleppmann.

View on Amazon
Kafka: The Definitive GuideEditor's Pick

Real-time data and stream processing by Confluent engineers.

View on Amazon
Apache Kafka Series on Udemy

Hands-on Kafka course covering producers, consumers, Kafka Streams, and Connect.

View Course

Practical engineering notes

Get the next backend guide in your inbox

One useful note when a new deep dive is published: system design tradeoffs, Java production lessons, Kafka debugging, database patterns, and AI infrastructure.

No spam. Just practical notes you can use at work.

Sachin Sarawgi

Written by

Sachin Sarawgi

Engineering Manager and backend engineer with 10+ years building distributed systems across fintech, enterprise SaaS, and startups. CodeSprintPro is where I write practical guides on system design, Java, Kafka, databases, AI infrastructure, and production reliability.

Keep Learning

Move through the archive without losing the thread.

Related Articles

More deep dives chosen from shared tags, category overlap, and reading difficulty.

System DesignAdvanced

Speculative Retries: The Google Approach to Solving Tail Latency

Speculative Retries: Solving the P99 Tail In a large distributed system, the "tail latency" (P99.9) is often dominated by a single "slow" node. This is the Tail at Scale problem. No matter how much you optimize your code…

Apr 20, 20262 min read
Deep DiveDistributed Systems Mastery
#system-design#low-latency#p99
System DesignBeginner

System Design: Designing a Distributed ID Generator (Snowflake)

Designing a Distributed ID Generator > Prerequisite: To understand why distributed IDs are hard, first read about Database Sharding and Partitioning. In a distributed system, you often need to generate unique identifiers…

Apr 20, 20262 min read
Deep DiveBackend Systems Mastery
#system-design#snowflake#distributed-id
System DesignAdvanced

System Design: Designing Airbnb (Hotel/Home Booking)

System Design: Designing Airbnb (Hotel/Home Booking) Designing a platform like Airbnb or Booking.com involves two distinct technical challenges: Search (helping users find the perfect place) and Concurrency (ensuring tha…

Apr 20, 20263 min read
Deep Dive
#system-design#airbnb#booking-system
System DesignAdvanced

System Design: Designing a Distributed BLOB Store (like S3/GCS)

System Design: Designing a Distributed BLOB Store An object store (BLOB store) is a fundamental building block of cloud infrastructure. Unlike a file system, it provides a simple interface (PUT, GET, DELETE) to store lar…

Apr 20, 20262 min read
Deep Dive
#system-design#object-storage#distributed-systems

More in System Design

Category-based suggestions if you want to stay in the same domain.