Design an Ads Frequency Capping Service
Context
You are tasked with designing a service for an ad-supported video application that ensures users do not see the same ad creative or campaign more than a configured number of times within specified time windows. Examples include limits like "3 times per day per campaign" or "10 times per week across an advertiser".
This service must support real-time ad decisioning at high QPS (Queries Per Second) with sub-10ms p99 decision latency. It needs to accommodate multi-tenant advertiser onboarding and provide reliable reporting. The system will be deployed across multiple regions and must adhere to strict privacy and compliance requirements. It integrates with an existing ad server/selector, which provides candidate ads and expects an allow/deny decision before rendering.
Task
Design the complete frequency capping service. As part of your design, you should compare it to a generic rate limiter and highlight the additional components specifically required for multi-tenant advertiser configuration and onboarding.
Your design should cover the following key topics:
- Identity Resolution: How to identify users or households, considering cookies, device graphs, and logged-in IDs, and how to scope caps (e.g., per user, per household).
- Cap Dimensions: Supporting hierarchical caps and combinations across various dimensions like creative, ad group, campaign, and advertiser.
- Window Semantics: Implementing both sliding and tumbling windows, including calendar anchoring (e.g., day, week).
- Counter and Storage Design: Strategies for keying, bucketization, Time-To-Live (TTL), ensuring atomicity across multiple caps, and providing memory/scale estimates.
- Consistency vs. Latency Trade-offs: Discussing implications within and across regions, handling concurrency/race conditions, and defining acceptable overshoot.
- Real-time Decisioning at High QPS: API design, implementing a check/reserve/commit flow, considering batching/vectorized lookups, and managing concurrency.
- Configuration APIs and Validation: Designing APIs for cap configuration, defining schema, constraints, default caps, and targeting/scope.
- Config Propagation, Versioning, and Rollback: Strategies for distributing configurations, handling versions, implementing canaries, using pub/sub for caches, and planning for freezes/rollbacks.
- Backfill and Migrations: Addressing challenges like enabling new caps mid-flight, handling identity merges/splits, and data warmup.
- Reporting Needs: Designing for aggregates, rejection reasons, near-real-time dashboards, and data retention.
- Privacy and Compliance: Incorporating consent mechanisms, data minimization, retention policies, deletion workflows, and safeguards for cross-device linking.
- Failure Handling: Strategies for store outages, partial availability, stale configuration, and defining decision policies (fail-open vs. fail-closed).
AI interview prep
Core dilemma
Balancing extreme read/write throughput and sub-10ms latency for real-time ad decisioning with the need for accurate, consistent, and complex frequency count state management across diverse dimensions, time windows, and global regions, all while adhering to strict privacy and multi-tenant operational requirements.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design an Ads Frequency Capping Service
Context
You are tasked with designing a service for an ad-supported video application that ensures users do not see the same ad creative or campaign more than a configured number of times within specified time windows. Examples include limits like "3 times per day per campaign" or "10 times per week across an advertiser".
This service must support real-time ad decisioning at high QPS (Queries Per Second) with sub-10ms p99 decision latency. It needs to accommodate multi-tenant advertiser onboarding and provide reliable reporting. The system will be deployed across multiple regions and must adhere to strict privacy and compliance requirements. It integrates with an existing ad server/selector, which provides candidate ads and expects an allow/deny decision before rendering.
Task
Design the complete frequency capping service. As part of your design, you should compare it to a generic rate limiter and highlight the additional components specifically required for multi-tenant advertiser configuration and onboarding.
Your design should cover the following key topics:
- Identity Resolution: How to identify users or households, considering cookies, device graphs, and logged-in IDs, and how to scope caps (e.g., per user, per household).
- Cap Dimensions: Supporting hierarchical caps and combinations across various dimensions like creative, ad group, campaign, and advertiser.
- Window Semantics: Implementing both sliding and tumbling windows, including calendar anchoring (e.g., day, week).
- Counter and Storage Design: Strategies for keying, bucketization, Time-To-Live (TTL), ensuring atomicity across multiple caps, and providing memory/scale estimates.
- Consistency vs. Latency Trade-offs: Discussing implications within and across regions, handling concurrency/race conditions, and defining acceptable overshoot.
- Real-time Decisioning at High QPS: API design, implementing a check/reserve/commit flow, considering batching/vectorized lookups, and managing concurrency.
- Configuration APIs and Validation: Designing APIs for cap configuration, defining schema, constraints, default caps, and targeting/scope.
- Config Propagation, Versioning, and Rollback: Strategies for distributing configurations, handling versions, implementing canaries, using pub/sub for caches, and planning for freezes/rollbacks.
- Backfill and Migrations: Addressing challenges like enabling new caps mid-flight, handling identity merges/splits, and data warmup.
- Reporting Needs: Designing for aggregates, rejection reasons, near-real-time dashboards, and data retention.
- Privacy and Compliance: Incorporating consent mechanisms, data minimization, retention policies, deletion workflows, and safeguards for cross-device linking.
- Failure Handling: Strategies for store outages, partial availability, stale configuration, and defining decision policies (fail-open vs. fail-closed).