How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Netflix.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Netflix during technical interviews.

Design ads frequency capping service | Netflix Interview Question

Quick Overview

This question evaluates a candidate's ability to design a low-latency, high-QPS, multi-tenant frequency capping service, testing competencies in identity resolution, hierarchical cap modeling, window semantics, counter and storage architecture, consistency versus latency trade-offs, real-time decisioning APIs, configuration/versioning, backfill, reporting, privacy/compliance, and failure handling. It is commonly asked to assess systems-design proficiency in distributed systems, databases, caching, API design, and operational reliability; it belongs to the System Design domain and emphasizes practical application with system-level conceptual reasoning rather than purely algorithmic detail.

Design an Ads Frequency Capping Service

Context

You are designing a service that ensures a user does not see the same ad creative or campaign more than a configured number of times within specified time windows (for example, 3/day per campaign, 10/week across an advertiser). The service must support real-time ad decisioning at high QPS with low latency, multi-tenant advertiser onboarding, and reliable reporting.

Assume an ad-supported video application with: high read QPS during ad selection, sub-10 ms p99 decision latency, multi-region deployment, and strict privacy/compliance requirements. The system integrates with an ad server/selector that provides candidate ads and expects an allow/deny decision before rendering.

Task

Design the frequency capping service and compare it to a generic rate limiter. Explain the extra components required for advertiser configuration and onboarding.

Cover the following topics:

Identity resolution: cookies, device graph, logged-in IDs; user/household scoping.
Cap dimensions: creative, ad group, campaign, advertiser (hierarchical caps and combinations).
Window semantics: sliding vs tumbling windows and calendar anchoring (day/week).
Counter and storage design: keying, bucketization, TTL, atomicity across multiple caps, memory/scale estimates.
Consistency vs latency trade-offs: within and across regions; concurrency/race conditions; acceptable overshoot.
Real-time decisioning at high QPS: API design, check/reserve/commit flow, batching/vectorized lookups, concurrency.
Configuration APIs and validation: schema, constraints, default caps, targeting/scope.
Config propagation, versioning, and rollback: canaries, pub/sub to caches, freeze/rollback plans.
Backfill and migrations: enabling new caps mid-flight, identity merges/splits, data warmup.
Reporting needs: aggregates, rejection reasons, near-real-time dashboards, retention.
Privacy and compliance: consent, minimization, retention, deletion, cross-device linking safeguards.
Failure handling: store outages, partial availability, stale config, decision policy (fail-open vs fail-closed).

Also include a brief comparison to a generic rate limiter and highlight the additional components needed for advertiser onboarding and configuration.

Quick Overview

Context

Task

Design the frequency capping service and compare it to a generic rate limiter. Explain the extra components required for advertiser configuration and onboarding.

Cover the following topics:

Identity resolution: cookies, device graph, logged-in IDs; user/household scoping.

Cap dimensions: creative, ad group, campaign, advertiser (hierarchical caps and combinations).

Window semantics: sliding vs tumbling windows and calendar anchoring (day/week).

Counter and storage design: keying, bucketization, TTL, atomicity across multiple caps, memory/scale estimates.

Consistency vs latency trade-offs: within and across regions; concurrency/race conditions; acceptable overshoot.

Real-time decisioning at high QPS: API design, check/reserve/commit flow, batching/vectorized lookups, concurrency.

Configuration APIs and validation: schema, constraints, default caps, targeting/scope.

Config propagation, versioning, and rollback: canaries, pub/sub to caches, freeze/rollback plans.

Backfill and migrations: enabling new caps mid-flight, identity merges/splits, data warmup.

Reporting needs: aggregates, rejection reasons, near-real-time dashboards, retention.

Privacy and compliance: consent, minimization, retention, deletion, cross-device linking safeguards.

Failure handling: store outages, partial availability, stale config, decision policy (fail-open vs fail-closed).

Also include a brief comparison to a generic rate limiter and highlight the additional components needed for advertiser onboarding and configuration.

Design ads frequency capping service

Quick Overview

Design an Ads Frequency Capping Service

Context

Task

Solution

Comments (0)

Design ads frequency capping service

Quick Overview

Design an Ads Frequency Capping Service

Context

Task

Solution

Comments (0)