How Configuration Reaches the Ad Server

The ad server never queries the database while serving. It works from an in-memory snapshot of everything that can serve, and that snapshot is refreshed automatically after every change.

What the snapshot contains

Active publishers and ad units, orders, line items, approved creatives, audience segments, custom domains and the settings the waterfall needs (floors, block lists, wallet solvency). Only approved creatives and active entities are included, so a draft or a creative still in review can never serve.

How changes propagate

  1. You save a change in the dashboard — a new ad unit, a line item edit, a creative approval.
  2. The backend bumps the configuration version and, about one second later (bursts of edits are batched), tells the ad server to sync.
  3. The ad server fetches the rebuilt snapshot and swaps it in atomically. Requests in flight finish on the old snapshot; the next request uses the new one.
  4. As a safety net the ad server also re-syncs on its own every 15 seconds, so a missed notification heals itself.

There is no publish button you need to press and no downtime. Network admins have a Publish Config action that forces a sync immediately.

What this means in practice

  • A change is live within seconds — typically one, at most about fifteen.
  • If something does not serve after that, the cause is eligibility (dates, budget, targeting, an unapproved creative), not publishing. Publishers can see why requests ended without an ad on Delivery → Tag Health.
  • There is no draft/production split, snapshot history or rollback: the snapshot always reflects the current state of your account.