
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.

![Alt text](https://res.cloudinary.com/dggmcsp1z/image/upload/v1763781282/ad_click_image5_psiiwc.png)

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.


A system that collects and aggregates data on ad clicks

Ad Click Aggregator System Design


# Sorting Algorithms

This is a brief overview of common sorting algorithms used in Data Structures and Algorithms.

## Bubble Sort
A simple comparison-based algorithm where adjacent elements are compared and swapped if they are in the wrong order.

## Merge Sort
A divide-and-conquer algorithm. It divides the array into two halves, sorts them, and then merges them.

## Quick Sort
Also a divide-and-conquer algorithm. It picks a 'pivot' element and partitions the other elements into two sub-arrays, according to whether they are less than or greater than the pivot.

Common Sorting Algorithms

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.

![[simple_arch.png]]

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.


Posts

2025

Undated