Design an ad click-through rate prediction system: system design interview question

How the interviewer opens it

“Design a service that predicts the probability that a user will click a candidate advertisement. The service must return calibrated probabilities at low latency and use fresh user, ad, and context features.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Service boundary
Scale
Read and write traffic
Latency and availability
Feature freshness and consistency
Click labels
Prediction quality
Model freshness and new entities
Durability and retention
Identity and privacy

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Return a click probability for each supplied candidate ad.
Use recent user, ad, and context features.
Record each prediction and join actual displays with later clicks.
Train, assess, and release calibrated models.

Usually out of scope

Select candidate ads.
Run auctions or manage ad budgets.
Predict purchases or other conversions.
Operate across multiple regions.

What interviewers ask about

Feature values at request time: Features change between prediction and training. Stale caches and fallback paths can make the actual prediction differ from any later reconstruction.
Impressions, clicks, and training examples: Most impressions have no click. Delayed events make recent negatives uncertain, and candidate ads without display have no observed outcome.
Probability quality and model changes: A model can rank ads well but return wrong probabilities. Aggregate quality can hide errors in fallback traffic or other important slices.
Prediction latency under load: Each request needs 20 probabilities and a durable record within 20 ms. Feature access and model execution share this limited budget.

Common mistakes

Treats the problem as model selection and omits the event, feature, and release paths.
Stores impression IDs but omits request context, served probabilities, or effective versions from durable prediction records.
Uses future feature values in historical training examples.
Labels unshown candidates or immature impressions as negative examples.
Uses accuracy or AUC as proof that probabilities are calibrated.
Ignores fallback traffic, negative sampling corrections, or durable record costs.

The bar by level

Senior (L5/E5): Defines exact prediction records and historical examples. Handles delayed labels and calibration. Budgets feature access, model execution, and durable commits within deadlines.
Staff (L6+/E6+): Defines durability and retention across every prediction path. Addresses display bias and fallback calibration. Plans zone failure capacity and evidence-based release gates.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design an ad click-through rate prediction system
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a service that predicts the probability that a user will click a candidate advertisement. The service must return calibrated probabilities at low latency and use fresh user, ad, and context features.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Service boundary

Scale

Read and write traffic

Latency and availability

Feature freshness and consistency

Click labels

Prediction quality

Model freshness and new entities

Durability and retention

Identity and privacy

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Return a click probability for each supplied candidate ad.
Use recent user, ad, and context features.
Record each prediction and join actual displays with later clicks.
Train, assess, and release calibrated models.

Usually out of scope

Select candidate ads.
Run auctions or manage ad budgets.
Predict purchases or other conversions.
Operate across multiple regions.

What interviewers ask about

Feature values at request time

Features change between prediction and training. Stale caches and fallback paths can make the actual prediction differ from any later reconstruction.

Impressions, clicks, and training examples

Most impressions have no click. Delayed events make recent negatives uncertain, and candidate ads without display have no observed outcome.

Probability quality and model changes

A model can rank ads well but return wrong probabilities. Aggregate quality can hide errors in fallback traffic or other important slices.

Prediction latency under load

Each request needs 20 probabilities and a durable record within 20 ms. Feature access and model execution share this limited budget.

Common mistakes

Treats the problem as model selection and omits the event, feature, and release paths.

Stores impression IDs but omits request context, served probabilities, or effective versions from durable prediction records.

Uses future feature values in historical training examples.

Labels unshown candidates or immature impressions as negative examples.

Uses accuracy or AUC as proof that probabilities are calibrated.

Ignores fallback traffic, negative sampling corrections, or durable record costs.

The bar by level

Senior (L5/E5)

Defines exact prediction records and historical examples. Handles delayed labels and calibration. Budgets feature access, model execution, and durable commits within deadlines.

Staff (L6+/E6+)

Defines durability and retention across every prediction path. Addresses display bias and fallback calibration. Plans zone failure capacity and evidence-based release gates.