Insights

Solution That Solves the Performance and Scalability Challenges of Ad Exchanges 

This is the story of how Avenga 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.

  • Client Internal project
  • Industry Programmatic advertising
  • Service AdTech
  • Technologies TypeScript, JavaScript, React, Formik, Redux, Fastify, TypeORM, Jest, ESLint

Introduction 

One 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. 

  • 3

    Core components of the solution

  • 9

    Technologies used in the stack

The aim of the project was to: 

  • Develop a solution that solves the challenges. 
  • Use the solution as the foundation for future SSP/ad exchange development projects. 

Challenge 

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: 

  • To maintain fast response times, the exchange has to rapidly scale. 
  • The inventory query can take a long time to complete and produce a big response. 
  • Inventory changes made by the user (e.g. a publisher or AdOps operating the SSP) have to be propagated to all exchange instances. 
  • The propagation process can not be performed after each update in the SSP as this would cause an unpredictable number of propagation operations, which could hinder the exchange’s performance. 

Without a proper solution to these challenges, SSP/ad exchange vendors face the following business problems: 

  • The publisher isn’t able to sell all their available inventory, resulting in low fill rates and less ad revenue. 
  • The publisher misses out on being able to display an ad to the visitor and potential ad revenue because the ad exchange doesn’t respond in time – typically, an RTB auction finishes within 250ms, meaning the ad exchange has to receive and respond to ad/bid requests within that time frame. 

Solution 

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:

• It allowed us to achieve the target levels of scalability, as each microservice can horizontally scale independently.
• We can deploy these services individually rather than as a whole, which reduces deployment time.
• Having a microservice architecture means that if one microservice becomes faulty, it will be isolated to that service and won’t impact the rest of the ad exchange.
The main performance challenges in an SSP/ad exchange relate to its ability to:

• Handle large numbers of inventory changes made in the SSP.
• Propagate these changes to all exchange instances.
• Ensure the ad exchange instances can handle this resource-heavy task without causing the SSP to experience unexpected performance issues.

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.

Process 

Understanding the Core Challenge

The team kicked off the project by identifying performance and scalability as the main barriers to running a high-performing real-time bidding (RTB) ad exchange.

Through internal R&D, they outlined specific technical pain points like delayed responses, inventory synchronization issues, and unpredictable system loads.

Designing a Scalable System

To tackle the scalability issue, the team adopted a microservice architecture combined with a horizontal scaling approach.

This made it possible for individual services to scale independently and handle more bid and ad requests without creating bottlenecks.

Solving Performance Bottlenecks

To maintain fast and stable performance under load, the team implemented a publish-subscribe (pub/sub) messaging layer and built a populator service.

These components ensured seamless communication between services and eliminated the risk of overwhelming the SSP with direct inventory queries.

Automating Inventory Synchronization

The populator service acted as a single point of communication, regularly pulling inventory updates from the SSP and distributing them across all exchange instances.

This setup enabled real-time inventory propagation without straining resources, ensuring up-to-date data was always available in memory for faster auctions.

Results 

Our SSP/ad exchange solution is designed to: 

  • Speed up the development phase of your custom-built SSP. 
  • Implement it into your existing SSP to improve performance and scalability. 

Ready to boost your ad exchange’s speed and scalability? Let’s build it right. 

Let`s talk

With a setup that’s built for real-time load and designed to handle inventory sync without delays, you’re no longer limited by outdated infrastructure or performance bottlenecks. It’s a future-ready foundation for companies looking to move faster without compromising stability.