Design Ad Serving Infrastructure for mobile apps

Question

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

Codemia · Accepted Answer

### Functional Requirements
1. **Ad Delivery**: The system must serve targeted ads to mobile app users based on their profiles and behavior.
2. **Analytics Tracking**: Collect and report user interactions with ads (impressions, clicks).
3. **A/B Testing**: Support for running experiments on ad effectiveness.
4. **Ad Inventory Management**: Allow advertisers to upload and manage their ads.

### Non-Functional Requirements
1. **Scalability**: Must handle up to 10 million requests per minute.
2. **Low Latency**: Ad serving requests should complete in under 100ms.
3. **High Availability**: The system should be up 99.99% of the time.
4. **Consistency**: Strong consistency for ad inventory updates, eventual consistency for analytics data.

Assuming we expect to handle up to 10 million requests per minute, we can break it down:
- **Requests per second**: 10 million / 60 = ~166,667 RPS.
- **Data Size**: Each ad response may be ~1 KB, leading to a bandwidth requirement of ~166,667 KB/s (~160 MB/s).
- **Storage Needs**: If we assume 5 million ads with an average size of 5 KB, we need ~25 GB of storage for ad inventory.
- **Analytics Data**: If each user interaction generates ~0.1 KB of data, with an estimated 1 million interactions per minute, we'll need ~100 MB/s for analytics storage.

### Component Diagram
1. **Load Balancer**: Distributes incoming requests across ad-serving instances.
2. **Ad Serving Service**: Microservice that fetches ads based on user data, using a caching layer.
3. **Database**: A distributed NoSQL database (e.g., Cassandra) for ad inventory and user profiles.
4. **Analytics Service**: Collects and processes ad interaction data, writing to a data warehouse (e.g., Amazon Redshift).
5. **CDN**: For serving static ad content quickly.

### Technology Choices
- **Load Balancer**: AWS Elastic Load Balancer.
- **Caching**: Redis for in-memory caching of frequently accessed ads.
- **Database**: Apache Cassandra for high write throughput and scalability.

### Ad Inventory Schema
- **Ad Table**:  
  - `ad_id (UUID, PRIMARY KEY)`  
  - `content (TEXT)`  
  - `targeting_info (JSON)`  
  - `status (ENUM('active', 'paused', 'deleted'))`  
  - `created_at (TIMESTAMP)`

### User Interaction Schema
- **Interaction Table**:  
  - `interaction_id (UUID, PRIMARY KEY)`  
  - `ad_id (UUID, FOREIGN KEY)`  
  - `user_id (UUID)`  
  - `timestamp (TIMESTAMP)`  
  - `action (ENUM('impression', 'click'))`

### Access Patterns
- Frequent reads for ad delivery, less frequent writes for ad updates, and analytics data captured in a batch process.

1. **Consistency vs. Availability**: Opting for eventual consistency in the analytics service allows for higher availability and performance but may result in some delays in reporting.
2. **Caching Strategy**: Using Redis for caching ads helps reduce load on the database but introduces a complexity of cache invalidation when ads are updated.
3. **Load Balancer Decisions**: Implementing a single-point load balancer can simplify architecture but may become a bottleneck; a multi-region setup can enhance resilience at the cost of complexity.
4. **Database Choice**: Cassandra offers high write scalability but requires careful data modeling to avoid performance pitfalls, such as read latencies.

Design Ad Serving Infrastructure for mobile apps

Grafana Labs

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

Grafana Labs 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