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 RTB | Delegate | |
|---|---|---|
| Latency | 50–150ms round-trip | <1ms (in-process) |
| Network dependency | Your datacenter | None |
| Timeout risk | Yes — circuit breaker triggers at <150ms | None |
| Bidder maintenance | Your team | None |
| Strategy updates | Redeploy | 30 seconds |
| Budget pacing | Your system | Integrated with Guide |
| Targeting granularity | Full (your code) | Conditions + multipliers |
| Debugging | Your logs | Dashboard + 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 updatedThe 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:
- New strategy saved to PostgreSQL
- Redis cache invalidated
- 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
creativein 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 in sandbox
Test your Delegate strategy against realistic auction parameters without spending real budget:
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.