This content originally appeared on HackerNoon and was authored by Sarthak Shah
An auction in an ad system is a bad place to do extra work. The request arrives at the server, and the server has very little time to respond and make several decisions. It must validate the request, parse it, apply rules, decide which demand partners should participate, run an auction to find the winner, and return a response before timeout.
When a system operates under that kind of time constraint, the usual engineering question is, “How do we make this faster?” That is a useful question, but it is not always the best one. A better question is, “Why are we doing unnecessary work during the auction at all?”
In Supply Side Platforms (aka SSPs), a lot of work happens in real time (hot/critical path) because the auction is where the final decision is made. But not every input to the decision needs to be in real time. Publisher settings, demand partner eligibility, experiments, regional constraints, inventory rules, and configurations often change much more slowly than the auction traffic that consumes them.
This mismatch pattern creates an important architectural opportunity. If something changes slowly but is evaluated frequently, there is no need to compute it from scratch every time a request arrives.
Real-Time Does Not Mean Everything Must Happen in Real Time
Digital advertising is built around real-time execution. A request comes in, buyers are contacted, bids are evaluated, and the platform must respond quickly. Because of this, most teams focus on optimizing the critical path through the following means:
- Fine-tune services
- Reduce network calls
- Optimize serialization and deserialization
- Add caching
- Autoscaling policies
These are valuable, but they assume that the work belongs in the hot path. Sometimes, the better answer is to remove some of this work from the hot path entirely.
The system must treat two speeds independently. The speed at which configurations change or constraints change is not the same as the speed at which they are executed.
The Auction Path Should Be Boring
Boring systems are predictable and do fewer surprising things. They have fewer dependencies and are easier to operate when traffic scales. A good real-time auction path should be boring.
In an ideal state, the auction path should receive a request, perform local lookups, read local state, perform bounded evaluation, run an auction, and respond. It should avoid unnecessary remote calls, repeated parsing and compilation of business rules, and expensive decisions that could be made prior.
The fastest path is not always the most optimized. It is more often the one that does less work. This is where many latency discussions become narrow. Teams focus on optimizing individual functions, service calls, or infrastructure settings. But they miss the big picture: the request path might be doing too much work.
Separation of Responsibility: Management vs. Execution
Software Defined Networking popularized the concept of Control Plane vs. Data Plane (also known as Execution Plane).
- Control Plane: The "brain" that makes decisions, defines constraints, and determines how the system or network should behave. In SDN, this is often centralized into a controller.
- Data/Execution Plane: The "muscle" that executes those decisions, processes actual traffic, or runs workloads. In networking, this forwards the packets.
This is one useful architectural lens for auctioning as well.
Authoring is where business intent, rules, inventory and publisher settings, buyer controls, experiments, and other configurations are created. This side of the system needs flexibility, validation, auditability, approvals, and rollback.
Execution is different. It is where these decisions are applied to live traffic. This side of the system needs speed, stability, predictable latency, and simple failure behavior.
The authoring side can be safe and expressive, while execution should be compact and fast. A configuration or structure may be more feasible for authoring but may not be the best structure for serving.
Pre-computation
It is easy to mistake pre-computation for caching, but caching is only part of the story.
Caching means storing something that can be reused later. Pre-computation goes a step further. It asks whether the system can prepare the response or part of it before the request arrives.
For SSPs, this could mean many things:
- Eligibility rules transformed into cheap evaluation structures
- Materializing partner/publisher settings closer to the serving path
- Validating complex configurations and compiling them before they are used in live traffic
Expensive decisions can be split such that the slow-changing portion can be pre-computed and the request-time portion stays small.
The real-time flow does not need to know the history of a decision. It just needs to know the state required to make the next decision within the available time frame.
Actual Trade-Off Is Freshness vs. Latency
Moving work out of the auction flow is powerful, but it comes at the cost of freshness.
If state is pre-computed ahead of time and distributed to the execution plane, there may be a propagation delay between when a change is made and when it is visible to everyone. For some, the delay is acceptable, but not for all. This is where architecture becomes more than just optimization. There needs to be clear versioning, propagation tracking, observability, safe defaults, and rollback behavior.
The system also needs to define a staleness threshold: “How stale is too stale?” Not every type of data has the same freshness requirements. Some updates need to be applied immediately, while others can be delayed.
The idea here is not to ignore freshness but to make the trade-off explicit.
Cost Optimization
Latency and cost are closely connected. A slow request does not only hurt response time, but it increases infrastructure cost as well. A slow request means more work per request and therefore more CPU. More waiting means more concurrency and more machines. At large scale, small inefficiencies become expensive very quickly.
So a better question for an SSP would be whether the system is doing unnecessary work in the auction path. The right cloud setup, autoscaling, and all of that come later once the workload is shaped properly.
The cheapest operation in a real-time system is the one the system never has to perform.
Not All Requests Are the Same
SSPs serve a variety of traffic. Some impressions are high value, some have strong demand, and some require more checks. Others are routine and can be handled through simpler paths.
A mature system should recognize that not every request deserves the same amount of work. It means recognizing high-value or complex cases that need deeper validation vs. simple cases where they do not need to pay the cost of the most complex path.
In a real-time advertising system, tail latency often matters more than the average because timeouts do not care that most requests were fast. A simpler execution path makes latency easier to operate.
Real-Time Systems Prepare Early
Better real-time systems are not fast without a reason or by accident. They are fast because they prepare. They move the slow-changing work off live traffic and keep the critical path small. They make local reads the default and treat remote calls as expensive. They carefully build distribution systems for propagation. They observe not only latency but freshness, versioning, and correctness.
For SSPs, this matters the most, as the auction path is directly tied to revenue. Every unnecessary operation that sits between the publisher and the outcome adds risk. Every avoidable delay increases cost.
The architecture question should not be limited to “Can this run faster?” It should also include “Should it run here?” This additional question can change the design.
Final Thought
The fastest decision is not always the one with the best micro-optimization. Sometimes the fastest decisions are the ones the system has pre-computed before the request arrives.
For SSPs, that is the opportunity. Move the slow-changing work away from the fast path. Keep the auction path simple and make the real-time system predictable. This is how latency improves and infrastructure cost comes down. And that is how real-time systems stay reliable when every millisecond matters.
This content originally appeared on HackerNoon and was authored by Sarthak Shah
Sarthak Shah | Sciencx (2026-09-18T13:44:52+00:00) The Fastest SSP Decision Is the One That Has Already Been Made. Retrieved from https://www.scien.cx/2026/09/18/the-fastest-ssp-decision-is-the-one-that-has-already-been-made/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.