Case Studies
Ad Click Aggregation
Streaming exact, dedup'd counts per ad per window from a massive click stream — because these numbers drive billing.
Turning a massive stream of click events into near-real-time counts per ad — a good vehicle for testing stream-aggregation design specifically, since the numbers here drive advertiser billing, which makes "roughly right" an unacceptable answer in a way most analytics systems can tolerate.
Think of a turnstile at a stadium gate: it has to count everyone who walks through, but if someone bumps it twice by accident, that's still one entry, not two. Ad click aggregation carries that same shape at a much larger scale.
What this lesson covers
Tag each click with a client eventId, partition by adId in Kafka so one consumer sees an ad's events in order, and count in tumbling windows with a bounded dedup set. Prefer at-least-once plus dedup to end-to-end exactly-once, and hold a grace period for late events.
- A turnstile bumped twice is still one entry: counts drive advertiser billing, so 'roughly right' is not acceptable.
- Exact per-ad, per-minute counts must appear on a dashboard within about a minute from an enormous, bursty click stream.
- Client retries are the double-counting risk; a senior answer proposes idempotency-key dedup without being asked.
- One viral ad can overload a single partition; salting the partition key is the mitigation to name unprompted.
- Staff answers weigh transactional exactly-once against cheaper at-least-once-plus-dedup, and place a grace period for late events.
Included in Plus and Pro
Continue reading “Ad Click Aggregation”
The full lesson works the design through end to end — diagrams, trade-offs, and what interviewers expect at each level. About 18 minutes.
- Understanding the Problem
- Functional Requirements
- Non-Functional Requirements
- Capacity Estimation
- Core Entities
- API Interface
- High-Level Design
- Trade-offs
- Final Design
- Operations & Observability
- Level Expectations
- Follow-Up Questions
- Try It Yourself