Design an Ad Serving System

• Return an ad within 80 ms at p99
• Peak of 60,000 ad requests per second (1.2M visitors, about one request every 20 seconds each)
• Choose ads using the visitor's context: location, device, page topic
• Never lose an impression or click event, but never block the ad response on recording it
• Let the ranking logic be rolled out to a slice of traffic first (A/B test)
• Keep infrastructure under $65,000 a month

Typical peak hour

The expected 60K requests per second arrive steadily.

Interviewer asks: Walk through one ad request from the page to the response. Which hops are on the critical path and which can be moved off it?

Big event traffic (2x)

A major live event doubles the request rate within minutes.

Interviewer asks: Which component saturates first when traffic doubles, and how would you scale it without re-architecting?

Ranking model slows down

The component that scores and ranks candidate ads becomes 6x slower.

Interviewer asks: The ranking step is suddenly slow. What does the visitor see, and how does your design protect the 80 ms budget?

Campaign cache is lost

The hot campaign data store disappears and every lookup falls through to the database.

Interviewer asks: With the cache gone, what absorbs the read load? Would you rather serve stale campaigns or fail?

Event pipeline outage

The queue that carries impression and click events goes offline.

Interviewer asks: Events cannot be queued. Do ads keep serving? Where are events held until the pipeline returns?

• Ads are returned within the latency budget at peak load
• At least 99% of requests are served during the 2x spike
• Total monthly cost stays within $65,000
• Impression and click events are recorded asynchronously (queue plus consumer)
• Something records impressions and clicks
• A slow ranking model cannot push responses past the latency target
• Event recording is decoupled from the ad response with an async link
• The design explains how ranking changes can be tested on part of the traffic