Katkat
Back

Design a Low-Latency Ad Serving Backend With Targeting, Budgets and Tracking

AmazonSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

An Amazon system design question: design an ad server that selects and returns an ad for each page request within a tight latency budget. It covers targeting and candidate retrieval, ranking and auctions, budget enforcement and pacing, impression and click tracking, and failure handling.

Design an ad server: the backend that receives an ad request each time a page or app screen with an ad slot loads, chooses which ad to show, returns it fast enough not to slow the page down, and records what was shown and clicked so that advertisers can be charged and budgets enforced.

The prompt was given only by name, so its standard scope is stated as assumptions:

  • Advertisers create campaigns with targeting rules (for example location, device, placement and audience segments), a bid, a daily budget and a schedule. Campaign management already exists; your focus is serving.
  • Each request describes the slot (placement and size) and the context (page or app, device, coarse location, and a user or session identifier when the user has consented).
  • The server returns at most one ad per slot, or no ad, within a tight latency budget, because the page is waiting.
  • Impressions and clicks are tracked for billing and reporting, and spend must not run far past a campaign's budget.
  • External real-time bidding exchanges and the training of the click-prediction model are out of scope unless the interviewer asks.

Clarifying Questions

  • How are advertisers charged: per impression, per click, or both?
  • What latency budget does the ad decision have, and what happens if it is exceeded?
  • What request volume, number of active ads and number of advertisers should I plan for?
  • How strict is budget enforcement: is a small overspend acceptable, and who absorbs it?
  • Are frequency caps, which limit how often one user sees the same ad, required?

Part 1 — Choosing and returning an ad

Describe the APIs, data model and components, and walk through what happens from the moment an ad request arrives until the response goes back: finding eligible ads, ranking them, choosing a winner and its price, and returning the creative. Explain how campaign changes made by advertisers reach the serving path.

What This Part Should Cover

  • Request and response APIs, including tracking links in the response
  • Candidate retrieval through a targeting index, then filtering and ranking by expected value
  • The auction and pricing choice, with a fallback when nothing qualifies
  • Propagation of campaign changes to the serving machines, and how stale they may be

Part 2 — Tracking, budgets and pacing

Explain how impressions and clicks are recorded, deduplicated and turned into spend, how that spend is fed back so a campaign stops before overspending its budget, and how a daily budget is spread across the day instead of being exhausted in the first hour.

What This Part Should Cover

  • Durable event logging, signed tracking links and deduplication
  • Real-time spend aggregation versus exact billing from the event log
  • Budget enforcement across many servers, and the overspend it tolerates
  • Pacing a budget over the day

Hints

Hint 1

The budget is milliseconds: Ask which data must already be in memory on the serving machines, and which lookups you could skip or approximate when they are slow.

Hint 2

Counting is distributed: Think about what happens when hundreds of serving machines spend the same campaign's budget at once and the spend figures they see are a few seconds old.

Follow-up questions

  • An advertiser pauses a campaign. How quickly does it stop serving, and what determines that?
  • How would you implement a frequency cap of a few impressions per user per day at this scale?
  • How would you detect and handle fraudulent clicks?
  • How would you add an external exchange as another source of ads within the same latency budget?