Design an Ad Serving System

Question

Design a real-time ad serving platform. Cover ad auction mechanics, CTR prediction integration, targeting based on user signals, budget pacing, frequency capping, and serving ads within strict latency budgets.

Codemia · Accepted Answer

- **Functional Requirements:**  
  1. **Ad Auction Mechanic:** Must support real-time auctions for ad placements based on bids, targeting, and CTR (click-through rate) predictions.  
  2. **Targeting:** Ability to target users based on demographics, user behavior signals, and contextual factors.  
  3. **CTR Prediction:** Integrate machine learning models to predict the CTR of ads based on user signals and historical data.  
  4. **Budget Pacing:** Ensure that ad budgets are spent according to pacing rules, distributing ad spends evenly over the designated time.  
  5. **Frequency Capping:** Limit the number of times a user sees the same ad within a specified time frame.  
  6. **Latency:** Serve ads with a maximum latency of 100 milliseconds.

- **Non-Functional Requirements:**  
  1. **Scalability:** The system must handle millions of requests per second, especially during peak times.  
  2. **Reliability:** 99.99% uptime is required, with failover mechanisms in place.  
  3. **Security:** Protect user data and ensure compliance with privacy regulations (e.g., GDPR).  
  4. **Maintainability:** Codebase should be modular and well-documented for easy updates.  
  5. **Cost Efficiency:** Optimize resource usage to minimize operational costs.

To estimate the capacity needed for the ad serving system, we can consider the following:  
- **User Base:** Assume 1 billion active users globally.  
- **Ad Requests:** If each user generates 10 ad requests per day on average, that results in:  
  
  1 billion users * 10 requests = 10 billion requests per day.  
  
- **Requests per second (RPS):**  
  10 billion requests / (24 hours * 3600 seconds) ≈ 115,740 requests per second.  
  
- **Peak Load:** Assuming a peak load of 5x the average, we need to prepare for approximately:  
  115,740 * 5 ≈ 578,700 requests per second.  
  
- **Storage Needs:** With an average of 100 bytes per ad request and 1 million ads stored, we would need around:  
  100 bytes * 1 million ads = 100 MB for the ad data storage.  
  
- **Total Data Volume:** Include user signals and logs, estimating an additional 1 TB of storage for analytics and CTR predictions.

The high-level architecture of the ad serving system includes the following components:  
- **Clients:** Web and mobile applications making ad requests.  
- **Load Balancer:** Distributes incoming requests to multiple ad servers to handle peak loads and ensure high availability.  
- **Ad Server:** Core component that processes ad requests, conducts real-time auctions, and serves the winning ads.  
- **Database:**  
  - **NoSQL Database (e.g., Bigtable):** For storing user profiles, ad details, and targeting information.  
  - **Relational Database (e.g., Cloud SQL):** For transactional data like bids and budget information.  
- **Machine Learning Service:**  
  - **CTR Prediction Service:** Utilizes TensorFlow for real-time CTR predictions based on user signals.  
- **Cache Layer (e.g., Redis):** Caches frequently accessed data such as user profiles and ad inventory to minimize latency.  
- **Analytics Service:** Processes user interactions for continuous improvement of targeting and CTR prediction models.

The data model for the ad serving system includes the following key entities:  
- **User:**  
  - `user_id` (Primary Key, String)  
  - `demographics` (JSON)  
  - `behavioral_signals` (JSON)  
  - `last_seen_ad` (String)  
  - `impression_count` (Integer)

- **Ad:**  
  - `ad_id` (Primary Key, String)  
  - `advertiser_id` (String)  
  - `content` (String)  
  - `targeting_criteria` (JSON)  
  - `budget` (Float)  
  - `bids` (Array of Objects)

- **Bid:**  
  - `bid_id` (Primary Key, String)  
  - `ad_id` (Foreign Key, String)  
  - `user_id` (Foreign Key, String)  
  - `bid_amount` (Float)  
  - `timestamp` (Datetime)

- **Impression:**  
  - `impression_id` (Primary Key, String)  
  - `ad_id` (Foreign Key, String)  
  - `user_id` (Foreign Key, String)  
  - `timestamp` (Datetime)  
  - `clicked` (Boolean)

This schema is designed to optimize for read-heavy operations and efficiently supports the ad auction and targeting functionalities.

Several architectural trade-offs were considered for the ad serving system:  
- **Real-time Processing vs. Batch Processing:**  
  - Chose a real-time processing model for immediate ad serving and auctioning, which increases complexity but meets strict latency requirements.  
- **NoSQL vs. SQL Database:**  
  - Opted for NoSQL for user profiles and ad data to scale horizontally and facilitate flexible schema design, while using SQL for transactional bid data to ensure ACID properties.  
- **Caching Strategy:**  
  - Implemented a caching layer to reduce latency for frequently accessed data, but this introduces potential cache invalidation issues that need to be managed.  
- **Machine Learning Model Complexity:**  
  - Chose a simpler model for CTR prediction to ensure lower latency in predictions, trading off some accuracy for speed.  
- **Cost vs. Performance:**  
  - Designed the system to use managed cloud services (e.g., Google Cloud) which may increase costs but significantly reduce operational overhead and improve scalability.

Design an Ad Serving System

Google

How to Approach This

Sharpen Your Skills on Codemia

Sample Answer

Requirements

Capacity Estimation

Submit Your Answer

Google Software Engineer Interview Guide

Related Questions

Design a high-throughput Inventory Management System

Design a low-latency Rate Limiting System

Design a fault-tolerant Payment System

Design a fault-tolerant Messaging System

Design Walmart Product Search