Download now, read later
Download the full version of this case study and read about how we solved the main technical challenges of an SSP/ad exchange.
DOWNLOAD PDF NOWSolving the main technical challenges of an SSP/ad exchange.
This is the story of how Clearcode developed a solution that solves the performance and scalability challenges of ad exchanges to help companies decrease development time when building a supply-side platform (SSP) or ad exchange.
The main challenges we chose to solve centered around scalability and performance.
![]()
Filip Dominas, Project Manager at Clearcode
Download the full version of this case study and read about how we solved the main technical challenges of an SSP/ad exchange.
DOWNLOAD PDF NOWOne of our AdTech development teams completed an internal research and development project that analyzed the main technical challenges of running a real-time bidding ad exchange.
The aim of the project was to:
The main challenges we chose to solve centered around performance and scalability.
Specifically, we wanted to build an ad exchange that could respond to a large number of ad and bid requests without any delay.
The main challenges we chose to solve centered around scalability and performance.
Specifically, we wanted to build an ad exchange that could respond to a large number of ad and bid requests without any delay.
During our initial research, we identified the following technical challenges:
Without a proper solution to these challenges, SSP/ad exchange vendors face the following business problems:
Based on our knowledge of SSP/ad exchanges and RTB, as well as extensive research, we developed the following solutions to the aforementioned challenges.
To ensure the ad exchange could scale – i.e. receive, handle and process more ad/bid requests – we deployed a microservice architecture coupled with a horizontal scaling pattern.
Microservice architecture is an architectural pattern used in software development projects to break down the application into individual and related services.
These services can be developed, deployed and maintained independently from the rest of the application and communicate between one another via application programming interfaces (APIs).
Adopting a microservice architecture provided us with the following benefits:
The main performance challenges in an SSP/ad exchange relate to its ability to:
To solve these challenges, we introduced inter-service communication over the publish-subscribe (pub/sub) layer and developed a populator service.
Pub/sub is a messaging pattern designed to publish and receive messages by subscribing to a specific channel or subject.
To carry out the pub/sub pattern, we opted for NATS, an open-source messaging service.
Its role in the SSP environment is to inform exchange instances about any inventory changes.
When we talk about inventory changes or changes in the inventory, we are referring to changes made to the following:
The ad unit’s checksum – e.g. if one has been added or removed.
The size of the ad slot – e.g. a square box (250x250) has been replaced with a vertical rectangle (240x400).
The advertising categories – e.g. sponsorships, premium guaranteed, audience targeted, and remnant.
Plus many other changes.
Due to the nature of the NATS services, pub/sub provides a simple, secure and fast solution to the messaging distribution challenge.
Since pub/sub is a queueless solution, it eliminates many problems associated with queues and their limitations.
Typically, when a change is made in an SSP, each exchange instance needs to download the changes in the inventory on startup.
If every exchange instance queries the SSP and downloads the inventory directly, serving those requests would require extensive resources and would likely crash the SSP.
To overcome this challenge, we introduced a populator service to function as a proxy and single point of communication between the exchange instances and the SSP, allowing us to achieve and ensure high performance.
The populator service notifies the exchange instances about new changes, updates the inventory in the exchange instances at a set interval, and prepares the inventory for easy loading.
This means the resource heavy task of providing the new inventory is performed in a predictable fashion, meaning there is no unexpected performance issues for the SSP.
Also, exchanges can always reliably download the latest inventory changes, even if the SSP is inaccessible.
The populator service:
In order to ensure it has the most up-to-date inventory, the exchange:
Once downloaded, the information is stored locally by the exchange instances.
Because of this setup, the exchange always has information about the inventory in its memory. In order to verify its validity, it doesn't need to download file storage, which would take a lot of time and resources; instead, it listens to the populator (pub/sub) for annotations regarding any changes in the inventory.
This results in faster performance, as there is no need to request the ad-slotIDs from the SSP each time an RTB auction is performed. The reason for this is because the exchange already has them stored in an in-memory database.
Faster performance translates to overall improvements in the ad/bid response time needed for conducting an RTB auction.
Stability: Because the inventory changes made in the SSP are queried only by the populator, they are predictable and independent of the number of updates in the system.
Scale: Our microservice architecture allows the SSP to deploy a large number of exchange instances, which ultimately results in more ad revenue for publishers.
Up-to-date inventory: The exchanges query the populator only when scaling up (on startup), meaning all exchanges are notified of inventory changes at the same time.
Improved performance: All exchanges download the new inventory at the same time, without placing any burden on the SSP or the populator.
Get in touch with our team and find out how we can help you build a new SSP/ad exchange or improve your existing platform.
Contact our team