Loading…

The decisions that matter

Append each click to a replicated log, then redirect.The user waits for one write, and a counting outage loses no clicks.
Identify each click, and save the job’s state with its log position.Double taps, resent batches and restarts don’t add clicks twice.
Count by the click’s own time, with early provisional results.Late clicks land in the right minute, and dashboards stay fresh.
Store totals by minute, hour and day.A chart reads a few rows per ad, whatever the click volume.
Bill from a daily final count over the raw clicks.Late clicks, missed repeats and fraud verdicts are all in, and the number can be produced again.

Architecture diagramThe final design at a glance

The redirect waits only for the log. Counting runs behind it for the live dashboards, and a daily final count over the raw clicks feeds invoices. Dashed lines are asynchronous.

Diagram as text

Components: Browser or app (Client); Click servers (Service); Click log (Kafka) (Queue); Counting job (Flink) (Worker); Standby log (Queue); Advertiser’s page (External API); Raw clicks, hourly files (Object store); Daily final count (Worker); Analytics store (Analytics); Fraud verdicts (SQL DB); Reporting API (Service); Advertiser dashboards (Client). Connections: Browser or app → Click servers (click link); Click servers → Click log (Kafka) (append, wait for ack); Click servers → Standby log (if the log is slow), asynchronous; Standby log → Click log (Kafka) (relay later), asynchronous; Browser or app → Advertiser’s page (after the 302); Click log (Kafka) → Counting job (Flink) (read); Counting job (Flink) → Analytics store (live minute totals); Click log (Kafka) → Raw clicks, hourly files (copy every click), asynchronous; Raw clicks, hourly files → Daily final count (a closed day), asynchronous; Daily final count → Analytics store (final counts); Fraud verdicts → Daily final count (invalid clicks), asynchronous; Analytics store → Reporting API (totals); Reporting API → Advertiser dashboards (provisional or final).

Understanding the problem

An ad network’s click link sends a user on to the advertiser’s page, and each click is money: advertisers pay per valid click. So the system has two customers with opposite needs. The user wants the redirect instantly; the advertiser wants numbers within a minute and a bill that is exactly right. The design keeps those two paths apart.

The practice brief states the requirements up front; in an interview you would confirm them in the first few minutes. The core is one write path, taking and keeping clicks, and two read paths: live dashboards and exact invoices.

Functional requirements

CoreA user who clicks an ad is sent on to the advertiser’s page, and the click is recorded.
CoreApp SDKs can send clicks in batches, including clicks from phones that were offline.
CoreAdvertisers see their clicks per ad and campaign, by country and device, over any time range.
CoreAdvertisers are invoiced for valid clicks, and can see the clicks behind an invoice.
Below the lineCounting impressions and click-through rates.
Below the lineConversions and attribution.
Below the lineBudgets and pacing.
Below the lineThe fraud model itself.Another team decides which clicks are invalid; this design records and applies its verdicts.
Below the lineAd-hoc queries over raw clicks.Advertisers get stored totals and exports; open-ended analysis belongs in a separate warehouse.

Non-functional requirements

LatencyThe click link adds no more than about 50 ms at p99.
AvailabilityUsers still reach the advertiser’s page when counting is slow or down.
ConsistencyEach valid click is billed once: never lost, never counted twice, however often it is sent.
ConsistencyA click is counted in the minute it happened, however late it arrives.
LatencyDashboards answer within about a second and show a click within about a minute.
DurabilityNo click is lost once the user has been sent on, even when a server fails.
Below the linePer-second freshness.The brief asks for about a minute, which lets the counting job batch its work and wait briefly for stragglers.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 20M active ads from about 1M advertisers.
ScaleAbout 2B clicks a day, peaking around 100,000 a second in big live events.
ScaleAbout 2,000 dashboard queries a second at peak.
ScaleApp clicks can arrive up to a day late.
ScaleClicks are explainable for about a year, for disputes.

Out of scope

Out of scopeChoosing which ad to show (the auction).
Out of scopePayments and pricing.

Check yourself

Why is it acceptable for the dashboard to be slightly wrong for a while?
Show answerHide answer
Because it says so. Live numbers are marked provisional, and the invoice comes from a later final count. Being exact on the dashboard as well would mean waiting for every late click and fraud verdict.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Work out only the numbers the design depends on, with rough figures. The surprise is how many fine-grained totals there can be.

Back of the envelope at the peak

Quantity	Value	Working
Clicks	About 100,000 a second	From the brief; the daily average is 2B ÷ 86,400, about 23,000 a second.
Raw clicks a day	About 1 TB	2B clicks × about 500 bytes: ids, two times, country, device.
Raw clicks kept	About 365 TB	A year of them, before compression.
Ad-minutes with a click	Up to about 1B a day	Most ads get a few clicks a day, so split by country and device, rows approach the click count.
Dashboard queries	About 2,000 a second	From the brief.

What the numbers tell you

The peak write rate sizes the click servers, the log and the counting job.
A year of raw clicks is the largest storage number, so where it lives decides the bill.
Fine-grained totals are not automatically small, which is why minutes are kept only briefly.

Architecture diagramWhere the load lands

Diagram as text

Components: Users clicking ads (User); Click servers (Service); Click log (Queue); Raw clicks, kept a year (Object store); Dashboards (Client); Stored totals (Analytics). Connections: Users clicking ads → Click servers (about 100,000 clicks/s); Click servers → Click log (every click); Click log → Raw clicks, kept a year (about 1 TB a day); Dashboards → Stored totals (about 2,000 queries/s).

Read:Learn: Numbers and capacity estimation

Try it: The numbers that shape the designGuided practice · Ad-click aggregator, Pay-per-click ad network · Senior

Check yourself

Why size for 100,000 clicks a second when the average is 23,000?
Show answerHide answer
The log and the job must take the peak without the redirect slowing down. Sizing for the average means the biggest events, the ones advertisers care about most, are the ones that fail.

Core entities: raw clicks and stored totals

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

There are two kinds of data with different lives. Raw clicks are the record: one row per click, append-only, in hourly files, kept for the dispute period. They carry the click’s own id and the id of the impression it came from, the times, and the result of the bot filters applied when the click arrived. The fraud team’s later verdicts go into their own append-only table rather than into the files.

Stored totals are what charts read: clicks per advertiser, campaign, ad, country and device, by the minute, summed into hours and days. A chart picks the coarsest totals that cover its range, so 90 days by day for 40 ads is 3,600 rows for each country-and-device pair shown, however many clicks there were.

The entities and their key fields

Entity	Key fields	Why it exists
Raw click	`click_id`, `impression_id`, ad, campaign, advertiser, placement, `clicked_at`, `received_at`, country, device, hashed device key, filter result	The record behind every number, kept for disputes.
Fraud verdict	the click, verdict, reason, `decided_at`, model version	Later decisions, kept apart so raw clicks stay unchanged.
Minute totals	advertiser, campaign, ad, minute, country, device, clicks	Recent charts; kept about a week.
Hour and day totals	the same, by hour or day	Longer charts; hours for months, days for two years.

Architecture diagramTotals by minute, hour and day

Read:Learn: Storage choice justification Learn: Data model design

Try it: What the system storesGuided practice · Ad-click aggregator, Pay-per-click ad network · Senior

Keep reading+1 min

Where the totals live

Use a store built for summing a few columns over a time range: a columnar analytics store, or a wide-column store keyed by (advertiser, campaign, ad) with time as the clustering key. Order the tables by advertiser, campaign, ad and time, which is how charts ask, and filter every query to the signed-in advertiser.

Check yourself

Why not keep one table of raw clicks with a good index and count them per chart?
Show answerHide answer

The API

The click and the reports are different contracts. The click link must be cheap and must reach the server every time, so it carries everything the redirect needs and is marked not to be cached (RFC 9111 (opens in a new tab)). The reporting API gives advertisers totals for a range and says how final they are.

The click and the reports

Call	Request	Response	Errors
`GET /c/{token}`	A signed token: impression, ad, placement, landing page, expiry	`302` to the landing page, `Cache-Control: no-store`	`404` bad token; `410` expired
`POST /v1/sdk/clicks`	A batch of app clicks, each with its click id and impression id	`202` accepted	`400`
`GET /v1/advertisers/{id}/metrics`	from, to, granularity, group by, filters, cursor	Rows of totals, `final_through`, next cursor	`400`; `403` another advertiser
`POST /v1/advertisers/{id}/exports`	An invoice	`202` and a job id	`403`, `404`

Read:Learn: API contract design Learn: Latency budgeting

Try it: The API: the click and the reportsGuided practice · Ad-click aggregator, Pay-per-click ad network · Senior

Keep reading+1 min

How apps send their clicks

The SDK records each tap with a click id, the impression it came from and how long after the ad was shown the tap happened. It sends clicks in small batches, keeps them while the phone is offline, and resends a batch that gets no reply with the same ids. The intake server appends the batch to the log and answers once it is stored; a batch sent twice is harmless, because the counting job recognises the ids.

Check yourself

Why put the landing page in the signed token instead of looking it up?
Show answer

High-level design

Build the design one path at a time. Each step adds only what that path needs; the deep dives then harden the parts an interviewer pushes on.

The click: store it, then redirect

The user waits for exactly one thing: the click being stored somewhere durable. The click server appends it to a replicated, partitioned log (Kafka here), waits for the acknowledgement with a short timeout, and returns the redirect. No database row is written per click, and nothing downstream is waited for.

The browser follows the click link to a click server.
The click server checks the token and appends the click to the log, waiting briefly for its replicas to acknowledge.
If the log is slow, it writes the click to a standby log instead, and a relay copies it over later.
It returns the 302, and the browser loads the advertiser’s page.

Architecture diagramThe click: store it, then redirect

The user waits for one append to a replicated log, not for counting. A standby log takes clicks while the main one is slow.

Diagram as text

Components: Browser (Client); Click server (Service); Click log (Kafka) (Queue); Advertiser’s page (External API); Standby log (Queue). Connections: Browser → Click server (GET /c/{token}); Click server → Click log (Kafka) (append, wait for ack); Click server → Standby log (log slow), asynchronous; Standby log → Click log (Kafka) (relay later), asynchronous; Browser → Advertiser’s page (after the 302).

Read:Learn: Write-heavy Learn: Apache Kafka

Try it: From a click to the advertiser’s dashboardGuided practice · Ad-click aggregator, Pay-per-click ad network · Senior

Keep reading+1 min

When the log itself is slow

The acknowledgement comes once the click is on more than one replica, so losing a single log machine loses nothing. If the log doesn’t answer within a short budget, set well inside the brief’s redirect target (for example, 20 ms of an illustrative 50 ms), the click server writes the click to a standby log cluster and redirects; a relay copies those clicks into the main log later, carrying their ids so nothing is counted twice. A spool on the click server’s own disk is cheaper, but a click server that dies takes the unsent clicks with it, which the brief rules out.

If both logs are down, the honest choice is to name the trade-off: fail the click, or redirect and record the loss.

Check yourself

From the log to the dashboard

A separate counting job (Flink here) reads the log and adds up clicks per ad per minute, by country and device. It writes minute totals to the analytics store, and hours and days are summed from them. The reporting API reads the totals. If counting stops for ten minutes, users are still redirected: clicks wait in the log, which keeps them for days, and the dashboard is late rather than wrong.

The counting job reads clicks from the log.
It adds them up per ad, per minute, per country and device.
It writes the minute totals; hour and day totals are summed from them.
A chart asks the reporting API for a range and granularity, and reads the totals.

Architecture diagramFrom the log to the dashboard

Keeping every click for disputes

A copy job moves every raw click from the log into cheap object storage as hourly, append-only files. They are kept for the dispute period, about a year, so any invoice can be explained click by click. An export job pulls the clicks behind an invoice when an advertiser asks.

The copy job reads the log and appends each hour’s clicks to a file.
The files are kept for the dispute period, then deleted.
An advertiser asks to export an invoice; the reporting API starts an export job.
The export job reads that month’s files and delivers the clicks.

Architecture diagramKeeping every click for disputes

Design an ad click aggregator

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities: raw clicks and stored totals

Where the totals live

The API

How apps send their clicks

High-level design

The click: store it, then redirect

When the log itself is slow

From the log to the dashboard

Keeping every click for disputes

Sign in with Google to read the rest

Practise this

Why a stream job, and not a query every minute

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities: raw clicks and stored totals

Where the totals live

04The API

How apps send their clicks

05High-level design

The click: store it, then redirect

When the log itself is slow

From the log to the dashboard

Keeping every click for disputes

Sign in with Google to read the rest

12Practise this

Why a stream job, and not a query every minute

Understanding the problem

The numbers that shape the design

Core entities: raw clicks and stored totals

The API

High-level design

Practise this