Problem Statement
Design a real-time ad frequency capping system for an ads platform. This system must enforce impression limits for users across various ad entities.
Core Requirements
- Frequency Caps: The primary cap is defined as "per user per campaign: at most
Kimpressions in the lastThours (rolling window)". The system should also optionally support caps for "per user per advertiser" and "per user per creative". - Performance: The system must operate with very low latency on the ad serving path, targeting a single-digit millisecond budget.
- Scale: It needs to handle very high Query Per Second (QPS), in the order of millions per second, and manage a large cardinality of users multiplied by campaigns.
- Event Handling: Impression events are generated on every ad view and may arrive late or out of order.
- Consistency: The design must explicitly define the required consistency model (e.g., strict vs. best-effort) and justify the associated tradeoffs.
- Time Windows: Support for multiple rolling time windows (e.g., 1 hour, 24 hours, 7 days) is required.
- APIs: Provide two distinct APIs:
check-and-reserve: Used at decision time by the ad server to determine if an ad can be shown and to tentatively reserve an impression count.impression-logging: Used to log a confirmed impression after an ad has been successfully displayed.
Deliverables
Explain the following architectural components and considerations:
- Data model
- Storage choices
- Write and read paths
- Deduplication strategy for impression events
- Time-To-Live (TTL) / data expiry mechanisms
- Sharding strategy
- Monitoring and alerting for correctness and system health
AI interview prep
Core dilemma
Balancing extreme real-time read/write throughput and low latency for rolling window counts across a massive cardinality, while handling late/out-of-order events and defining acceptable consistency tradeoffs for business impact.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Problem Statement
Design a real-time ad frequency capping system for an ads platform. This system must enforce impression limits for users across various ad entities.
Core Requirements
- Frequency Caps: The primary cap is defined as "per user per campaign: at most
Kimpressions in the lastThours (rolling window)". The system should also optionally support caps for "per user per advertiser" and "per user per creative". - Performance: The system must operate with very low latency on the ad serving path, targeting a single-digit millisecond budget.
- Scale: It needs to handle very high Query Per Second (QPS), in the order of millions per second, and manage a large cardinality of users multiplied by campaigns.
- Event Handling: Impression events are generated on every ad view and may arrive late or out of order.
- Consistency: The design must explicitly define the required consistency model (e.g., strict vs. best-effort) and justify the associated tradeoffs.
- Time Windows: Support for multiple rolling time windows (e.g., 1 hour, 24 hours, 7 days) is required.
- APIs: Provide two distinct APIs:
check-and-reserve: Used at decision time by the ad server to determine if an ad can be shown and to tentatively reserve an impression count.impression-logging: Used to log a confirmed impression after an ad has been successfully displayed.
Deliverables
Explain the following architectural components and considerations:
- Data model
- Storage choices
- Write and read paths
- Deduplication strategy for impression events
- Time-To-Live (TTL) / data expiry mechanisms
- Sharding strategy
- Monitoring and alerting for correctness and system health