Solving Performance and Scalability Challenges in Ad Exchanges: A Technical Use Case

The Scenario

Supply-side platforms and ad exchanges operate under extreme time constraints. An RTB auction must complete within 250ms from the moment an ad request is received to the moment a bid response is returned — leaving the exchange very little room for latency in any part of its processing pipeline. At the same time, exchanges are expected to scale rapidly as publisher inventory grows, absorb high volumes of concurrent bid requests, and always serve accurate, up-to-date inventory data.

This use case examines a technical R&D effort focused on addressing the core performance and scalability bottlenecks that commonly affect SSP/ad exchange architectures. The findings are applicable to any team building or maintaining a programmatic exchange.

Key Points

Goal: Solve the performance and scalability challenges that are common in SSPs and ad exchanges.

Solution #1: Address the scalability challenge by deploying a microservice architecture coupled with a horizontal scaling pattern.

Solution #2: Address the performance challenges by introducing inter-service communication over a publish-subscribe (pub/sub) layer and implementing a populator service.

Outcome: An ad exchange architecture with stable performance, the ability to scale inventory sold to DSPs, and consistently up-to-date inventory data.

Main Challenges

The central objective is to build an ad exchange that can respond to a large number of ad and bid requests without delay. Research in this area consistently surfaces four concrete technical challenges:

• Rapid scaling without latency degradation — to maintain fast response times, the exchange must be able to scale quickly to handle increased load.
• Heavy inventory queries — fetching inventory from the SSP can take a long time and produce large responses, creating a bottleneck.
• Propagation to all exchange instances — when a publisher or AdOps operator makes inventory changes in the SSP, those changes must reach every running exchange instance.
• Unpredictable propagation frequency — triggering a propagation operation after every SSP update would create an unpredictable and potentially unbounded number of operations, degrading exchange performance.

Left unaddressed, these challenges produce direct business consequences:

• Publishers are unable to sell all available inventory, resulting in low fill rates and reduced ad revenue.
• Because a typical RTB auction closes within 250ms, an exchange that cannot respond within that window causes impressions to go unsold — revenue that is simply lost.

The Approach

Solving Scalability: Microservice Architecture with Horizontal Scaling

To ensure the exchange can receive, handle, and process a growing volume of ad and bid requests, the appropriate architectural choice is a microservice pattern combined with horizontal scaling.

In a microservice architecture, the application is decomposed into individual services that can be developed, deployed, and maintained independently. Services communicate via APIs.

This approach delivers three concrete scalability benefits for an ad exchange:

• Independent horizontal scaling — each microservice can scale out on its own, without requiring the entire platform to scale together.
• Reduced deployment downtime — individual services can be deployed in isolation rather than requiring a full application redeploy.
• Fault isolation — if one microservice fails, the fault is contained to that service and does not cascade to the rest of the exchange.

Solving Performance: Pub/Sub Messaging and a Populator Service

The performance challenges are more nuanced. The exchange must handle large numbers of inventory changes, propagate them to all instances, and do so without placing unpredictable load on the SSP. Two mechanisms work together to solve this.

Inter-Service Communication via Pub/Sub

Pub/sub (publish-subscribe) is a messaging pattern in which publishers emit messages to a topic and subscribers receive them without direct coupling between sender and receiver. Unlike traditional queue-based systems, pub/sub is queueless — it eliminates a class of problems associated with queue depth, back-pressure, and queue management overhead.

For inventory change notifications in an SSP environment, NATS — an open-source messaging service — is a strong implementation choice. It provides a simple, secure, and fast transport for notifying exchange instances when inventory changes have occurred.

What Counts as an Inventory Change?

Inventory changes include any modification to:

• Ad unit checksums — e.g., an ad unit has been added or removed.
• Ad slot dimensions — e.g., a 250×250 square replaced with a 240×400 vertical rectangle.
• Advertising categories — e.g., sponsorships, premium guaranteed, audience-targeted, and remnant.
• Plus numerous other attributes tied to each placement.

The Populator Service

Under a naive architecture, each exchange instance would query the SSP directly to download updated inventory on startup. At scale, this is untenable — the volume of direct queries would consume extensive SSP resources and risk crashing it.

The solution is a populator service that acts as a proxy and single point of communication between all exchange instances and the SSP.

How the populator service works:

1. On startup, the populator queries the SSP for the full inventory.
2. It creates a unique hash of the response.
3. It stores the response as a file in an object storage service (e.g., Google Cloud Storage).
4. It publishes the file location to a pub/sub topic.
5. On a schedule, it re-queries the SSP for the inventory.
6. It compares the new response hash against the previous one.
7. If the hashes differ, it stores the updated response and publishes the new file location to the pub/sub topic.

How exchange instances consume this:

1. On startup, each exchange instance queries the populator for the current inventory file location.
2. It subscribes to the pub/sub topic to receive notifications of future inventory updates.
3. When notified, it downloads the new file and replaces its local inventory.

Once downloaded, each exchange instance keeps the inventory in memory. To validate whether its copy is current, it does not re-query file storage — it simply listens on the pub/sub channel for change notifications. This eliminates the need to fetch ad slot IDs from the SSP on every RTB auction, since the data is already resident in an in-memory store.

The result is meaningfully faster response times and the removal of per-auction SSP round-trips — both of which directly improve the exchange's ability to meet the 250ms RTB deadline.

Implementation Considerations

The technology stack used to implement this architecture included:

• TypeScript / JavaScript
• React
• Formik
• Redux
• Fastify
• TypeORM
• Jest
• ESLint

Outcomes and Tradeoffs

This architecture delivers four notable properties:

Stability: Because only the populator queries the SSP for inventory changes, the operation is predictable and independent of how frequently updates occur in the SSP itself. No matter how active publishers or AdOps teams are, the SSP is not bombarded with concurrent requests from multiple exchange instances.

Scale: The microservice model allows a large number of exchange instances to be deployed, enabling more inventory to be made available to DSPs and ultimately increasing publisher revenue potential.

Up-to-date inventory: Exchanges only query the populator at startup (scaling up). After that, they receive inventory updates via pub/sub notifications simultaneously — so all instances stay synchronized without polling.

Improved performance: All exchanges download new inventory at the same time without placing load on the SSP or the populator. In-memory storage of inventory data removes the need for repeated external lookups during live RTB auctions.

The primary constraint of this design is the dependency on the populator as a single coordination point. However, because the populator operates on a predictable schedule and exchange instances cache inventory locally, the system remains operational even if the SSP becomes temporarily inaccessible — exchange instances can continue serving auctions from their in-memory inventory until the next successful sync.

For teams building or refactoring an SSP or ad exchange, this pattern — microservices for scalability, pub/sub with a populator proxy for performance — represents a well-tested foundation for handling the demands of real-time programmatic trading at scale.