Design a system for online advertising.

Question

Anonymous · Accepted Answer

A good way to answer this is to start with the overall ad serving flow.
Interviewers are usually looking for whether you can design for massive read
traffic, very low latency, and analytics that can lag a little behind.

At a high level, I would break the system into four parts:

First, ad ingestion. This is where advertisers create campaigns, upload
creatives, define targeting, set budgets, and choose bids.

Second, ad serving. A user request comes in, the system finds all eligible ads,
ranks them quickly, and returns the best one.

Third, the event pipeline. Impressions, clicks, and conversions are logged
asynchronously so the serving path stays fast.

Fourth, analytics and billing. This layer aggregates metrics, handles pacing,
watches for fraud, and generates reports.

For the read path, the app sends context with the request, like the user, page,
device, and location. The ad server then filters down to ads that are actually
eligible based on targeting rules and budget state. After that, it ranks those
ads using a score that usually combines bid value with predicted quality, and
returns the winner.

The key thing here is speed. I would not want this path depending on slow raw
database reads. Instead, I would keep active campaign state in a distributed
cache and use some kind of index or search layer for fast targeting lookups. The
general principle is: serve from precomputed state, not from transactional
storage.

For the write path, every impression and click should first go into a durable
log, then get processed asynchronously by stream workers. Those workers can
update counters like impressions, clicks, spend, CTR, and remaining budget.

This is where an important design tradeoff comes up. My default would be
eventual consistency for analytics and dashboards, because that keeps the
serving path simple, fast, and scalable. But if the interviewer asks about
strict budget enforcement, I would add a dedicated budget service with atomic
counters or near-real-time spend checks.

The hardest problems in systems like this are usually:

* keeping ad selection extremely fast under huge read volume

* pacing budgets so campaigns do not spend too early in the day

* handling “hot” campaigns during major traffic spikes

* dealing with fraud, retries, and duplicate events

If I wanted to summarize the scaling approach, I would say: shard campaign data
across nodes, use aggressive caching, push all events through a queue like
Kafka, and aggregate metrics with streaming jobs. If a campaign gets unusually
hot, replicate or cache its metadata more broadly so one shard does not become a
bottleneck.

Design a system for online advertising.

Practice this question with AI

Go Premium

Community Answers

Unlock Full Access

Practice More Questions