sys

An Ad Click Aggregator is a system that collects and aggregates data on ad clicks. It is used by advertisers to track the performance of their ads and optimize their campaigns. For our purposes, we will assume these are ads displayed on a website or app, like Facebook.

More usage:

• Instagram post clicks
• Youtube video clicks
• Website/app/banner clicks

Functional Requirements

1. The system should be able to register the click and redirect if needed to actual ad location.
2. Provide mechanism for query the impressions by clients

Non functional Requirements

1. Scalable for over 10k tps
2. As realtime as possible
3. Fault tolerant and accuracy

Simple architecture:

• We need a public endpoint which can be hit by client device on user click action served by some backend server.

We can handle this in two ways:

1. Route to redirect url at client side (==Client side redirect==):
   1. Here, the redirection url comes along with Ads in some metdata and on user clicking it, it will redirect at client side using js while making a parallel call to /register_click POST event to inform server about the same.
   2. ==Problem==:
      1. User can grab the redirect url from Ad and may skip our impression recording system.
      2. Many validation (security ones based on tokens) have more chances on invalidation.
2. ==Server side redirect==:
   1. The redirection happens through server side components using HTTP Response 3xx.
   2. We will always validate all the details, token etc for consistent and more accurate data.
   3. We can add additional tracking params to sent redirect params based on our usecase.

Problem with this approach:

• Server is doing many things causing bottleneck for high tps.
• Direct dependency to sync call to DDB would become a problem.

Improved Architecture:

We can decouple the storage/processing of click event from app server whose responsibility just remains to validate the request and pass on the event to some other systems which will work on that asynchronously leaving app server quickly return the response and serve another request. The improved architecture can be broken down into three components:

1. Client side interaction to app server
2. Decoupling app server to data processing pipeline
3. Data processing to storage in suitable databases

1: Client-Server architecture

The question which are trying to solve here is how should we expose the click event attribute to users and what responsibility should our app server contains?

As shown earlier, we need to expose a public endpoint /register_click accessible to the client, we can have few ways to host the same...

1. API Gateway + Lambda -> Easy to setup, scale, cold start issue
2. ELB + EC2 -> Fastest, max performance
3. API Gateway + EC2 -> similar to #1 without cold start but with some additional cost

Read more on ELB and API Gateway.