Developer GuideFeaturesDelegate – Co-Located Bidding

Delegate – Co-Located Bidding

Traditional RTB requires your bidder to respond to every auction within 150ms over the public internet. Delegate eliminates the network entirely: your bidding logic runs inside Praevis infrastructure, evaluated in under 1ms, with no round-trip, no timeout risk, and no bidder to maintain.


Traditional RTB vs Delegate

Traditional RTBDelegate
Latency50–150ms round-trip<1ms (in-process)
Network dependencyYour datacenterNone
Timeout riskYes — circuit breaker triggers at <150msNone
Bidder maintenanceYour teamNone
Strategy updatesRedeploy30 seconds
Budget pacingYour systemIntegrated with Guide
Targeting granularityFull (your code)Conditions + multipliers
DebuggingYour logsDashboard + API

How Delegate works

When a bid request arrives and the demand source (DSP) is in Delegate mode:

1. Bid request arrives at auction engine
         ↓
2. Delegate engine loads DSP strategy from Redis cache
         ↓
3. Rules evaluated in priority order
         ↓
4. First matching rule → bid config used
         ↓
5. Effective bid calculated (base_cpm × multipliers, clamped to min/max)
         ↓
6. Bid submitted to auction as if it came from a traditional DSP
         ↓
7. If winner: impression tracked, spend debited, Guide updated

The entire Delegate evaluation takes <0.2ms in typical cases. It runs synchronously inside the auction goroutine — no IPC, no network, no Redis lookup at auction time (strategy is pre-loaded into memory).


Strategy loading and caching

Strategies are stored in PostgreSQL and cached in Redis per DSP:

Key: delegate:strategy:{dsp_id}
TTL: 60 seconds (refreshed on strategy update)

When you update a strategy via the dashboard or API:

  1. New strategy saved to PostgreSQL
  2. Redis cache invalidated
  3. All exchange pods pick up the new strategy within 30 seconds (next cache miss)

There is no redeployment, no restart, no downtime.


Who Delegate is for

Demand sources without bidder infrastructure

Running a bidder is expensive: servers, latency optimisation, monitoring, on-call. Delegate lets you buy programmatic inventory with a JSON file instead of a full stack.

Demand sources optimising for win rate

Delegate bids are evaluated in-process — they always “win” the timing race. Traditional bidders risk being timed out even at 140ms. Delegate is immune to this.

Latency-sensitive inventory

CTV auctions in regions where your datacenter is far away (e.g., a London-based bidder buying Dubai CTV inventory) face real latency disadvantages. Delegate bids from inside Praevis’s FRA pod eliminate the round-trip entirely.

A/B testing bidding strategies

Iterate on Delegate strategy JSON without a redeploy cycle. Test in sandbox, update, deploy in 30 seconds.


What Delegate can’t do

Delegate is a rules engine, not a full bidder. It cannot:

  • Access external data sources at bid time (user data, first-party data lookups)
  • Run ML model inference
  • Implement complex frequency capping (basic daily budget pacing via Guide is supported)
  • Return dynamic creative selection (specify creative in the bid config for static selection)

For these capabilities, use traditional RTB.


Strategy reference

Full JSON strategy format, all condition fields, multipliers, and examples:

→ Delegate Strategy Guide


Delegate in sandbox

Test your Delegate strategy against realistic auction parameters without spending real budget:

→ Testing Delegate in sandbox


Security model

Delegate strategies run in the Praevis Go auction process — not in a sandboxed VM. Strategy JSON is strictly validated on save (schema check, type check, condition key whitelist). Malformed or invalid strategies are rejected at save time, not at auction time.

Strategy JSON cannot execute arbitrary code — it’s declarative data, not code. The Delegate engine is the code; your strategy is configuration.