Design Ad Serving Infrastructure for mobile apps

Question

Design a real-time ad serving system that handles millions of requests. Discuss trade-offs in consistency, availability, and performance.

Codemia · Accepted Answer

### Functional Requirements:
1. **Ad Delivery**: Serve personalized ads to users in real-time based on user profile, location, and behavior.
2. **Tracking**: Track impressions and clicks for each ad served to measure effectiveness.
3. **Reporting**: Provide real-time analytics dashboard for advertisers to view performance metrics.
4. **User Management**: Manage user profiles and preferences for ad personalization.
5. **Ad Inventory Management**: Enable advertisers to upload, manage, and categorize their ads.

### Non-Functional Requirements:
1. **Scalability**: The system should handle millions of requests per minute, with the ability to scale horizontally.
2. **Availability**: Aim for 99.99% uptime to ensure ads are served without interruptions.
3. **Latency**: Ad serving should have a response time of less than 100 ms.
4. **Security**: Implement secure access controls and data encryption to protect user information and ad data.

To estimate capacity, consider the following assumptions:
- **Daily Active Users (DAU)**: 10 million users
- **Ad Requests per User**: 5 requests per session
- **Sessions per User per Day**: 3 sessions

### Calculation:
- Total Ad Requests = DAU * Ad Requests per User * Sessions per User per Day
- Total Ad Requests = 10,000,000 * 5 * 3 = 150,000,000 requests per day.
- Peak Load: Assuming peak traffic is 5x the average, we would need to handle about 625,000 requests per minute during peak times.
- Given this, the system should be designed to handle at least 1 million requests per minute to accommodate future growth and spikes in traffic.

### Component Diagram:
1. **Client Layer**: Mobile applications that send ad requests.
2. **Load Balancer**: Distributes incoming requests across multiple servers to ensure even load.
3. **Ad Serving Service**: Core service responsible for fetching and serving ads, implemented in Node.js for non-blocking I/O.
4. **Ad Database**: NoSQL database (e.g., MongoDB) for storing user profiles and ad inventory for quick access.
5. **Redis Cache**: In-memory caching layer to store frequently accessed ads and user profiles to reduce latency.
6. **Analytics Service**: A separate service that processes click and impression data, using Apache Kafka for event streaming.
7. **Reporting Dashboard**: A BI tool that interfaces with the analytics service to provide real-time metrics.

### Schema Design:
**User Profile Table (NoSQL Document)**:
- `userId`: String (unique identifier)
- `location`: String
- `interests`: Array of Strings
- `lastActive`: Timestamp

**Ad Inventory Table (NoSQL Document)**:
- `adId`: String (unique identifier)
- `advertiserId`: String
- `content`: String (ad content)
- `targetAudience`: Array of Strings (user interests)
- `budget`: Float

### Access Patterns:
- Quick lookups for ads based on user interests and location.
- Frequent updates to user profiles as user behavior changes.

### Architectural Decisions:
1. **Consistency vs. Availability**: Given the nature of ad serving, we prioritize availability over strict consistency. Ads may be slightly stale but should always be served quickly. A caching layer (Redis) allows for faster retrieval of ads.
2. **SQL vs. NoSQL**: Chose NoSQL (MongoDB) for flexibility in handling varied ad formats and structures, allowing rapid iteration and schema changes without downtime.
3. **Synchronous vs. Asynchronous Processing**: For tracking impressions and clicks, we use asynchronous processing through Kafka to decouple the ad serving process from analytics, thus ensuring faster response times for ad requests.
4. **Load Balancing Strategy**: Implemented a round-robin load balancer to evenly distribute traffic, but could consider a smarter strategy (like least connections) if specific servers become bottlenecks.

Design Ad Serving Infrastructure for mobile apps

Compass

What the Interviewer Expects

Key Topics to Cover

How to Approach This

Possible Follow-up Questions

Practice a Similar Problem on Codemia

Sample Answer

Requirements

Functional Requirements:

Capacity Estimation

Submit Your Answer

Compass Product Manager 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