Design an Ad Click Aggregator

Count a million ad clicks a second, show advertisers a dashboard that is seconds behind, stop a campaign the moment its budget runs out, and be exactly right when the invoice is cut.

Last updated 2026-09-22. Difficulty: hard. Patterns: stream-processing, windowing, exactly-once, olap, analytics. Reported at Meta and 5 more with Pro.

Functional requirements

• Record every click and redirect the user instantly. The click is a redirect on the critical path of a real person going to a landing page. It must be logged in single-digit milliseconds or not at all.
• Aggregate by campaign, creative, geography and time. Advertisers slice by whatever they like. The cube is small in dimensions and huge in rows.
• Near-real-time dashboards. Clicks and spend visible within seconds, so a campaign manager can react during a launch rather than the next morning.
• Budget enforcement. Stop serving a campaign once its daily budget is spent. Seconds of lag here is money given away.
• Exact numbers for billing. The dashboard may be approximate; the invoice may not. Both numbers come from the same events and must be reconcilable.
• Deduplicate clicks and filter invalid traffic. A double-submitted redirect, a retry, a crawler and a click farm must not all be billed as demand.
• Out of scope. Ad serving and auction (the decision of which ad to show), attribution of conversions after the click, and the advertiser-facing campaign editor.

Non-functional requirements

• Ingest rate (1 M clicks/s peak). Roughly 50 billion a day. Impressions would be a hundred times this; clicks are the expensive, billable subset.
• Redirect latency (p99 < 10 ms). A human is waiting on this hop. Logging must be fire-and-forget to a local buffer, never a synchronous database write.
• Dashboard freshness (< 10 s). Advertisers accept "a few seconds behind". They do not accept an hour, and they do not need the last millisecond.
• Billing accuracy (exactly once, reconciled daily). Every billable click counted once, with an audit trail from the raw event to the invoice line.
• Durability of raw events (no loss, 13 months). Raw events are the source of truth for disputes and for recomputation when the aggregation logic changes.
• Query latency (p95 < 1 s for a month of one campaign). Dashboards are interactive. Scanning raw events per query would never meet this.
• Budget enforcement lag (< 5 s). Overspend is refunded out of our own pocket, so this lag has a direct, measurable cost.

Back-of-envelope estimates

• Clicks per day: ~50 B. 1 M/s at peak, and peak is roughly twice the average over a day: ~0.5 M/s × 86 400 ≈ 50 B clicks/day.
• Raw event size and daily volume: ~400 B · ~20 TB/day. Click id, timestamp, campaign, creative, placement, user hash, geo, device, referrer, cost: ~400 B raw, ~100 B compressed columnar. 50 B × 400 B = 20 TB/day raw, about 5 TB stored.
• Raw retention: ~2 PB. 13 months × 5 TB/day compressed = ~2 PB in object storage. Cheap, and the thing that makes a recount possible when a billing bug is found.
• Aggregated rows per day: ~100 M. Minute buckets × ~1 M active (campaign, creative) pairs × a handful of dimension combinations, after rollup: ~100 M rows/day at ~100 B = 10 GB/day. Four orders of magnitude smaller than the raw stream, which is the entire point of pre-aggregation.
• Dedupe window state: ~2 B ids · ~30 GB. A 30-minute dedupe window at 1 M/s is ~1.8 B click ids. Stored exactly that would be ~50 GB; a partitioned Bloom filter at 1 % false positives is ~2 GB per window, so the choice is exactness against memory.
• Kafka partitions: ~1 000. 1 M events/s ÷ ~1–2 k events/s per partition that a single consumer thread handles comfortably = ~1 000 partitions, keyed by campaign id so all events for a campaign land in order on one consumer.
• Dashboard query cost: ~45 k rows scanned. One campaign, one month, minute granularity: 43 200 rows in the aggregate table. A columnar store answers that in milliseconds. The same question over raw events would scan tens of billions of rows.

Components

• User click: A real person clicking an ad and expecting to arrive at the advertiser's page. Everything on this path is measured against the delay they perceive, which is the reason the ingest design looks the way it does.
• Click endpoint (edge PoP · stateless): Verifies the signed click token, writes the event to a local buffer, and issues a 302 to the landing page. No database, no lookup, no blocking write: a few hundred microseconds of work.
• Collector: Batches buffered events from the edge and produces them to the log with a durable ack. The edge is fire-and-forget; the collector is where the durability promise actually begins.
• Event log (Kafka · ~1 000 partitions by campaign): The backbone. Partitioned by campaign id so every consumer sees a campaign's events in order, retained for a few days so a broken consumer can be rewound rather than losing data.
• Dedupe & filter (stream job): Drops repeated click ids inside a rolling window and tags obviously invalid traffic: known bots, impossible click rates per user, clicks with no preceding impression. Tags rather than deletes, so a mistake is reversible.
• Stream aggregator (Flink · tumbling minute windows): Keyed by (campaign, creative, geo, minute), counting clicks and summing cost. Checkpointed state, watermarks for late events, and idempotent writes downstream so a replay after a crash does not double-count.
• Serving store (columnar OLAP): Pre-aggregated minute buckets rolled up to hour and day. Answers dashboard queries by scanning tens of thousands of rows instead of tens of billions. Upserts by window key, so a window can be corrected in place.
• Budget controller: Keeps a running spend per campaign in memory from the same stream, compares it to the daily budget, and publishes a pause the moment it is exceeded. Separate from the aggregator because it trades accuracy for latency and nothing else in the system should.
• Ad serving: The auction and serving system. It subscribes to pause and pacing signals; it is not part of this design, but the latency of the loop back to it is what determines overspend.
• Raw archive (object store · Parquet by hour): Every event, partitioned by hour and campaign, written by a sink consumer. The audit trail and the input to any recount. Untouched by the fast path.
• Batch reconciler (nightly, over the archive): Recomputes each hour from the raw archive with the full dedupe window and the final invalid-traffic verdicts, then corrects the serving store. The number the invoice is built from.
• Billing: Reads the reconciled, closed days and produces invoice lines. It never reads the streaming numbers, so a bad minute in the stream can never become a bad charge.
• Advertiser dashboard: Interactive slicing over the serving store, labelled with how fresh the numbers are and whether the day is still provisional. The label is a design decision, not decoration: it is what stops support tickets about two numbers disagreeing.

User flows

1. One click, from redirect to dashboard. The path everything else hangs off. Note what is not on it: no database write, no lookup, no synchronous aggregation.
   1. The user clicks; the edge validates the signed token and redirects immediately. The token was signed when the ad was served and carries campaign, creative, placement and price. Because everything needed is inside it, the edge needs no lookup: that is what makes a sub-10 ms redirect possible at a million a second.
   2. The event is appended to an in-process buffer and flushed in batches to the collector. Batched every few hundred milliseconds. A node that dies with a full buffer loses a fraction of a second of clicks; making this durable at the edge would cost the latency budget. It is a deliberate, quantified trade and it should be said out loud.
   3. The collector produces to the event log with acks from all in-sync replicas. Keyed by campaign id, so every event for a campaign lands on one partition in order. From here on nothing is lost: the log is the durability boundary.
   4. Dedupe and filtering drop repeats and tag suspicious traffic. Click id against a rolling window; then cheap heuristics: a data-centre IP range, an impossible click rate for one user hash, a click with no matching impression. Tagged, not deleted: a false positive should be recoverable from the archive.
   5. The aggregator folds the event into its minute window and upserts the bucket. State is keyed by (campaign, creative, geo, minute). The window is emitted on the watermark and re-emitted if late events arrive, and the write is an upsert on the window key so re-emission corrects rather than doubles.
   6. The dashboard reads the bucket seconds later. End to end is a few seconds: batch flush, log, window emit, upsert. The dashboard states its own freshness so nobody has to guess.
2. A campaign hits its daily budget. The one place latency costs money directly. A separate, faster, less accurate path exists purely for this.
   1. The budget controller keeps running spend per campaign from the same clean stream. In-memory counters, no windowing and no waiting for watermarks. It deliberately does not wait for late events: being right two minutes later is worthless here.
   2. Spend crosses the daily budget and a pause is published immediately. Published to the serving system on a low-latency channel, not through the data warehouse. The loop (click, count, pause, stop serving) is what determines overspend, so every hop in it is minimised.
   3. Serving stops within a couple of seconds; clicks already in flight still arrive. An ad already rendered on someone's screen can still be clicked. Some overspend is structural, not a bug; the design bounds it rather than eliminating it.
   4. Overspend beyond a threshold is absorbed rather than billed. The standard commitment is to charge no more than the budget, so anything over it is written off. That write-off is the metric that justifies spending engineering effort on this loop.
   5. As the budget resets or is raised, the controller unpauses. Also the recovery path after a controller restart: it rebuilds today's spend by reading the serving store for closed minutes plus the stream tail, rather than replaying the whole day.
3. Traffic triples during a live event. The scale-breaking case. The log absorbs the burst and the consumers fall behind, which is exactly what should happen.
   1. Click rate goes from 1 M/s to 3 M/s in a minute. The edge is stateless and already sized for redirects, which cost almost nothing. It is the first thing that would have failed in a design that wrote to a database on the click path, and it does not even notice here.
   2. The collector keeps producing; the log takes the write rate. A partitioned log absorbing a burst is the whole reason it is in the middle. Disk is cheap and sequential writes are fast; the buffer is what turns a spike into lag instead of loss.
   3. Consumer lag grows and dashboards drift from seconds to minutes behind. The correct degradation. Nothing is lost and nothing is wrong: the numbers are simply older, and the dashboard says so instead of pretending.
   4. Aggregator instances scale out; partition assignment rebalances. Parallelism is capped by partition count, which is why partitions are provisioned generously up front: adding them mid-incident changes key-to-partition mapping and disturbs ordering per campaign.
   5. The budget path is prioritised over the reporting path while lag persists. If something must be behind, let it be the dashboard. Lag in the budget loop costs real money; lag in reporting costs patience. Separate consumer groups make that choice possible.
   6. The spike passes and consumers catch up by draining the backlog. Windows emit in order as the backlog drains, and because writes are upserts keyed by window, catching up corrects the dashboard rather than double-counting it.
4. A worker crashes mid-window. The failure path that decides whether the numbers can be trusted. Replay must not double-count.
   1. An aggregator instance dies holding uncommitted window state. Its partitions are reassigned. Anything held in memory since the last checkpoint is gone, which is fine as long as the input can be replayed.
   2. The replacement restores the last checkpoint and rewinds the log to that offset. Checkpoints bundle operator state with the offsets that produced it, so state and position are always consistent with each other. This is what "exactly once" actually means in a stream processor: at-least-once delivery plus atomic state and offsets.
   3. Events between the checkpoint and the crash are processed a second time. Unavoidable, and harmless here, because the sink is idempotent. A design whose sink appended deltas would over-count on every single crash.
   4. Windows are re-emitted and upserted by key, overwriting rather than adding. The window emits an absolute total for its key. Replay writes the same total. Idempotency lives in the shape of the write, not in a distributed transaction.
   5. Events arriving after their watermark are counted into a correction, not dropped. Allowed lateness of a few minutes re-opens the window and re-emits it. Beyond that, events still land in the raw archive and are picked up by the nightly reconciliation, so nothing is ever silently lost: it is just late.
   6. The archive sink, on its own consumer group, was unaffected throughout. Independent consumer groups mean an outage in the aggregation path costs freshness, never the record. The audit trail survives every failure in the fast path.
5. The nightly recount that produces the invoice. Two paths from the same events: one fast and approximate, one slow and exact. Billing only ever reads the second.
   1. After the day closes, the reconciler reads the raw archive for each hour. Complete, ordered, and with no watermark pressure: every late event has long since arrived. The batch job can afford the exactness the stream cannot.
   2. Dedupe runs over the whole day, not a rolling window. A duplicate separated by two hours is invisible to a 30-minute streaming window and obvious to a full-day pass. This is the main reason the two numbers differ, and being able to explain that difference is the job.
   3. Final invalid-traffic verdicts are applied, including ones that need hindsight. Some fraud patterns are only visible after the fact: a user hash that clicked four hundred ads across the evening looks ordinary at the time. Those clicks are reclassified as invalid and credited back.
   4. The serving store is corrected and the day is marked final. Same upsert path as the stream, so corrections flow through one mechanism. The dashboard flips from provisional to final, and the delta between the two is recorded: a drift above about a percent is an alert, not a curiosity.
   5. Billing reads only finalised days and produces invoice lines. It never reads a provisional number. That one rule is what keeps a bad minute in the stream from ever becoming a bad charge, and it is what makes disputes answerable: every line traces back to archived raw events.

Deep dives

Related

• Design a URL Shortener
• Design Search Autocomplete
• Run this question for a friend: the interviewer kit