Data Flow

Understanding how data moves through Praevis helps you interpret metrics, diagnose issues, and build integrations with realistic expectations about latency and data freshness.

Full request lifecycle

1. Ad request arrives
   Publisher's app/ad server → rtb.praevis.com
   Protocol: VAST (GET) or OpenRTB (POST)

2. Defender IVT check (~0.5ms)
   IP rate limit / bot database / UA check / geo anomaly
   Rejected → 200 empty VAST or 204 no-bid

3. Pathfinder DSP selection (~0.2ms)
   Load eligible DSPs from Redis cache
   Filter by pool, geo, format, circuit breaker, budget

4. Auction (~2–8ms)
   Send bid requests to eligible DSPs (traditional RTB)
   OR evaluate Delegate strategies (in-process)
   Collect bids → select winner (highest bid above floor)

5. Response to publisher
   Filled: VAST XML with winning creative URL
   Empty: <VAST version="4.0"/> passback

6. Creative renders (viewer's device)
   VAST player fetches creative from DSP's CDN

7. Impression tracking (~100–500ms after render)
   Publisher's player fires impression pixel
   → rtb.praevis.com/track/impression
   Revenue accrued to publisher's Redis counter

8. Metrics aggregation (every 60s)
   Stream aggregator reads Redis event stream
   Aggregates by publisher, DSP, region
   Writes to Redis time-series + PostgreSQL

9. Dashboard update (every 5s)
   WebSocket server reads Redis
   Pushes updated snapshot to connected browsers

Where data lives

Data	Storage	Retention	Purpose
Live counters (RPS, revenue_micros)	Redis	Rolling 24h	Real-time dashboard
Time-series metrics (1m, 1h buckets)	Redis	7 days	Dashboard charts
Auction logs (every event)	PostgreSQL	90 days	Billing, reconciliation, audit
Daily aggregates	PostgreSQL	90 days	Historical reporting
Billing records	PostgreSQL	7 years (planned)	Invoice, compliance
Delegate strategies	PostgreSQL + Redis cache	Indefinite	Demand source (DSP) strategy evaluation
Supply source config	PostgreSQL + Redis cache	Indefinite	Pathfinder eligibility

Latency at each step

Step	Typical latency
Request arrives → Defender check	~0.5ms
Defender → Pathfinder	~0.2ms
Pathfinder → Auction start	~0.1ms
Auction (Delegate, in-process)	<1ms
Auction (Traditional RTB, waiting for bids)	5–140ms
Response to publisher	Total <10ms (Delegate) / <150ms (RTB)
Impression fires → Redis counter update	<5ms
Impression → metrics aggregation	Up to 60s
Metrics aggregation → dashboard update	Up to 5s
Total: request to dashboard visibility	~60–65 seconds

Multi-region data flow

Praevis operates in three regions — FRA (Frankfurt), NYC (New York), LON (London):

FRA ──────────────────────────────────────────────┐
  Auction engine                                  │
  Redis (live metrics, Pathfinder cache,          │ Each region
  Delegate strategy cache, Guide QPS)             │ operates
  PostgreSQL (primary → replication to NYC/LON)   │ independently
NYC ────────────────────────────────────────────── │
  Auction engine                                  │
  Redis (local copy)                              │
  PostgreSQL (replica of FRA)                     │
LON ──────────────────────────────────────────────┘
  Auction engine
  Redis (local copy)
  PostgreSQL (replica of FRA)

No cross-region auction data sharing: A request that arrives at FRA is processed entirely in FRA. It does not cross to NYC or LON. Data sovereignty is maintained — EU auction data stays in FRA, US data in NYC, UK data in LON.

Cross-region coordination (Guide): Budget pacing state is shared across regions via Redis so a demand source’s daily budget is enforced globally, not per-region.

Supply source → metrics lag explained

Supply sources frequently ask: “I just got a VAST fill, why isn’t it in the dashboard?”

The path from auction to dashboard:

Impression fires → Redis counter incremented immediately
Stream aggregator runs every 60 seconds — batches all events in that window
WebSocket server reads Redis every 5 seconds → pushes to dashboard

Maximum lag: 65 seconds from impression to dashboard visibility.

For instant confirmation that a request was received, use the API:

GET /api/supply/sources/{publisher_id}/stats?period=1h

If impressions has incremented, the auction succeeded. The dashboard will reflect it within 65 seconds.

Sandbox data flow

Sandbox data follows the same pipeline but uses separate Redis keys (sandbox:*) and PostgreSQL rows flagged sandbox = true. Sandbox metrics never appear in production dashboards or invoices.

Flushing sandbox data (POST /api/sandbox/reset) clears the sandbox Redis namespace only — production data is unaffected.

If you flush production Redis (e.g., during infrastructure maintenance), live metrics reset but PostgreSQL historical data remains intact. The dashboard falls back to PostgreSQL automatically for periods >7 days.

Pricing Model From SpringServe