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

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. ```hint 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. ``` #### 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. ```hint 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. ``` #### 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 ### What a Strong Answer Covers - Requirements and scale stated up front, with latency as the dominant constraint - A clear split between the low-latency decision path and the asynchronous event path - Sound reasoning about ranking by expected value rather than raw bid - Budget and pacing control that works with delayed, distributed counts - Failure handling that degrades gracefully rather than blocking the page - Observability: fill rate, per-stage latency, spend versus budget, pipeline lag ### 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?