Design an ad frequency-capping system
Quick Overview
This question evaluates a candidate's competency in designing distributed, low-latency stateful systems for ad delivery, including consistency and atomicity reasoning, storage and messaging choices, high-QPS scaling, and operational failure-mode handling; it is in the System Design domain with an ad-tech and distributed-systems focus.
Netflix
Jan 30, 2026, 12:00 AM
Software Engineer
Onsite
System Design
8
0
Design a frequency capping system for an ads platform.
Goal: For each (user, campaign) (or (user, ad)), enforce rules like:
- “Show at most K impressions per time window (e.g., 3 per day, 10 per week).”
- Some advertisers require strictly enforced caps (never exceed K), while others can tolerate small eventual-consistency errors.
Requirements to address:
- Serving path (online): very low latency decisioning at ad request time.
- Write path: increment impression counts when an impression happens (or when it is considered billable).
- Traffic/scale: high QPS, many users, many campaigns.
- Atomicity: explain why atomic updates matter and how you guarantee them.
- Storage choice: e.g., Redis and its modes (single instance, replication, cluster), plus any durable store.
- Offline path: batch recomputation/backfill, fraud filtering, late events; how you reconcile with online counters.
- Messaging: if you use a queue/stream, specify what, why, and how keys/partitioning are chosen.
- Failure modes: duplicates, retries, out-of-order events, cache loss, hot keys, partial outages.
Produce a clear architecture and justify key trade-offs between strict vs best-effort capping.
Solution
Show