Design an Ads Event Reporting System
Design the system that ingests ad impression, click, and conversion events and serves advertiser reporting: impressions, clicks, spend, and conversions by campaign, ad group, and ad, over time, with near-real-time dashboards. Billing has to be exact.
Two consumers with different contracts: dashboards want minute-level freshness and tolerate small later corrections; billing wants exactness and can wait hours. Dedup rules (one billable click per impression within 24 h, duplicate event ids dropped) change over time, so raw events must be kept. Mobile clients batch and retry, so events arrive hours late — conversions up to 30 days (the attribution window). Dimensions: advertiser → campaign → ad group → ad, plus time, country, device, placement. Ingestion must never block ad serving.
Cover: where exactly-once actually matters and how you get it, event time and lateness, the click-to-impression join, hot keys from viral promoted pins, and how a billing bug gets backfilled.
Hints
Hint 1
Say the two-consumer split first — it is the whole design. Streaming feeds dashboards within a minute and may be slightly wrong; batch over exactly-once raw data owns billing truth and periodically overwrites the streaming aggregates.
Hint 2
"Exactly-once" is a property of the pipeline, not a queue flag: idempotent producer + client event ids, checkpointed streaming state with an upsert sink, atomically committed batch partitions, and a ledger keyed by run id that replaces rather than increments.
Hint 3
A viral promoted pin can be 5% of all impressions — one hot key. Pre-aggregate under (ad_id, salt), flush partials, merge keyed by ad_id; and partition the OLAP store by time, not advertiser.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.