Design a Real-Time Ad Serving System with Budgets and Impression Tracking

Design an ad serving system. When a web page or app has an ad slot to fill, it sends an ad request to your system. The system must pick one ad from the active campaigns the request is eligible for, and return it fast enough for the page to render. Afterwards it must record what was shown and what the user did with it (impressions and clicks), so that advertisers can be billed and their campaign budgets are respected. Each campaign has targeting criteria (for example location, device type or audience segment), a budget, a bid, and one or more creatives (the ad content in each format). Cover the ad request path end to end. Explain how campaign data reaches the serving path and stays fresh, how impressions and clicks are recorded, and how spend is tracked against budgets. ```hint Split the hot path Separate what must happen before the ad is returned from what can happen after the response. Then ask where each piece of campaign data must live so it can be read within the request's latency budget. ``` ```hint Budgets under concurrency Many serving nodes spend the same campaign's budget at the same time. Think about how far spend can overshoot the budget before every node learns that the campaign is exhausted. ``` ### Constraints and Clarifications - Advertisers create and edit campaigns through an existing management tool, which writes the campaign definitions. You design the serving side and the event pipeline behind it. - No traffic, campaign-count or latency figures were given. State the numbers you assume and size the design from them. ### Clarifying Questions - How is the winner chosen among eligible ads: highest bid, bid weighted by predicted click-through rate, or a fixed priority? Is click prediction in scope, or provided by another team? - What is the latency budget for an ad response, and what should be returned when it cannot be met: a fallback ad, or no ad? - Are advertisers billed per impression or per click, and how much budget overspend is acceptable? - Are frequency caps required, such as a limit on how often one user sees the same campaign per day? - How quickly must a new, edited or paused campaign take effect on the serving path? ### What a Strong Answer Covers - A request path with candidate retrieval by targeting, filtering (budget, pacing, frequency cap, slot fit), ranking and response, and a latency budget for each stage - Campaign data held in memory on the serving nodes, with a defined mechanism and bound for its freshness - Impression and click recording as an asynchronous, durable, deduplicated pipeline that feeds billing and spend tracking - Budget enforcement and pacing across many serving nodes, with an explicit bound on overspend - Fallbacks when dependencies are slow or down, fraud and duplicate handling, and the metrics that show the system is healthy ### Follow-up Questions - How would you pace a daily budget so that it is spread across the day instead of being spent in the first hour? - How would you enforce per-user frequency caps without a database read on every request? - An advertiser pauses a campaign. How long until it stops serving everywhere, and how would you shorten that? - After an outage, the click stream is replayed. How do you make sure advertisers are billed exactly once?