Architecture: Ad Server, SSP, and DSP

Three services: a control plane you use through the dashboard, an ad server that decides at open time, and an optional prediction service.

Control plane

The dashboard and its API hold accounts, ad units, orders, line items, creatives, wallets and reports. Every change that affects serving is pushed to the ad server automatically within seconds (how configuration reaches the ad server).

Ad server

The ad server answers the image request when a subscriber opens an email. It works entirely from an in-memory snapshot — no database query on the request path — and uses Redis for counters such as frequency caps, pacing and budgets.

Request flow

1. At send time, the ESP fills each subscriber's SHA-256 email hash into the ad tag in the template.
2. On open, the mail client requests /adserver/display.
3. The ad server checks the publisher, ad unit and subscriber value, then runs every eligible line item through the waterfall filters (dates, budgets, pacing, frequency cap, targeting, floor, brand safety).
4. Survivors are ranked: roadblocks, then sponsorships, then the rest by expected value (CPM adjusted by predicted click-through). If nothing fills and the ad unit has OpenRTB enabled, connected exchanges can bid.
5. The winning image is returned in the response and the impression is recorded; billing runs asynchronously.
6. Clicks go through /adserver/click, which records the click and redirects to the destination.

Accounts and isolation

Publishers, advertisers and agencies are separate accounts; one login can belong to several. Every API request is scoped to the account in the session (Security and RBAC).