Understand the Problem
With the rise of Facebook, YouTube, TikTok, and the online media economy, digital advertising is taking an ever-bigger share of the total advertising spending. As a result, tracking ad click events is very important. In this chapter, we explore how to design an ad click event aggregation system at Facebook or Google scale.
Before we dive into technical design, let’s learn about the core concepts of online advertising to better understand this topic. One core benefit of online advertising is its measurability, as quantified by real-time data.
Digital advertising has a core process called Real-Time Bidding (RTB), in which digital advertising inventory is bought and sold. Figure 1 shows how the online advertising process works.
The speed of the RTB process is important as it usually occurs in less than a second.
Data accuracy is also very important. Ad click event aggregation plays a critical role in measuring the effectiveness of online advertising, which essentially impacts how much money advertisers pay. Based on the click aggregation results, campaign managers can control the budget or adjust bidding strategies, such as changing targeted audience groups, keywords, etc. The key metrics used in online advertising, including click-through rate (CTR) 1 and conversion rate (CVR) 2, depend on aggregated ad click data.
Step 1 – Understand the problem and establish design scope
The following set of questions helps to clarify requirements and narrow down the scope.
What is the format of the input data?
It’s a log file located in different servers and the latest click events are appended to the end of the log file. The event has the following attributes: ad_id, click_timestamp, user_id, ip, and country.
What’s the data volume?
1 billion ad clicks per day and 2 million ads in total. The number of ad click events grows 30% year-over-year.
What are some of the most important queries to support?
The system needs to support the following 3 queries:
-
Return the number of click events for a particular ad in the last M minutes.
-
Return the top 100 most clicked ads in the past 1 minute. Both parameters should be configurable. Aggregation occurs every minute.
-
Support data filtering by ip, user_id, or country for the above two queries.
Do we need to worry about edge cases? I can think of the following:
- There might be events that arrive later than expected.
- There might be duplicated events.
- Different parts of the system might be down at any time, so we need to consider system recovery.
That’s a good list. Yes, take these into consideration.
What is the latency requirement?
A few minutes of end-to-end latency. Note that latency requirements for RTB and ad click aggregation are very different. While latency for RTB is usually less than one second due to the responsiveness requirement, a few minutes of latency is acceptable for ad click event aggregation because it is primarily used for ad billing and reporting.
With the information gathered above, we have both functional and non-functional requirements.
Functional requirements
-
Aggregate the number of clicks of ad_id in the last M minutes.
-
Return the top 100 most clicked ad_id every minute.
-
Support aggregation filtering by different attributes.
-
Dataset volume is at Facebook or Google scale (see the back-of-envelope estimation section below for detailed system scale requirements).
Non-functional requirements
-
Correctness of the aggregation result is important as the data is used for RTB and ads billing.
-
Properly handle delayed or duplicate events.
-
Robustness. The system should be resilient to partial failures.
-
Latency requirement. End-to-end latency should be a few minutes, at most.
Back-of-the-envelope estimation
Let’s do an estimation to understand the scale of the system and the potential challenges we will need to address.
-
1 billion DAU.
-
Assume on average each user clicks 1 ad per day. That’s 1 billion ad click events per day.
-
Ad click QPS = events / seconds in a day = 10,000
-
Assume peak ad click QPS is 5 times the average number. Peak QPS = 50,000 QPS.
-
Assume a single ad click event occupies 0.1 KB storage. Daily storage requirement is: 0.1 KB * 1 billion = 100 GB. The monthly storage requirement is about 3 TB.
Finished reading?
Mark it complete to track your progress.