Katkat
Back

Design a Distributed Frequency-Capping Service

NetflixSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Tests the ability to design an ultra-low latency, highly available counting and rate-limiting system for ad frequency capping across distributed environments, balancing consistency with latency trade-offs.

Scenario

In an ad-supported streaming service, advertisers want to restrict the number of times a specific viewer sees the same ad or campaign within defined time windows (e.g., "no more than 2 impressions per user per hour", or "no more than 5 impressions per user per 24 hours"). Frequency capping prevents viewer fatigue and maximizes unique reach for advertisers.

You are tasked with designing a distributed frequency-capping service that the ad-decisioning pipeline queries in real time to filter out ineligible candidate ads before running an auction or selection algorithm.

Requirements

Functional Requirements

  • Check Eligibility: Given a viewer identifier (user_id or device_id) and a list of candidate ad/campaign IDs, evaluate which ads satisfy their frequency constraints.
  • Record Impression: Once an ad is actually selected and served to the client, increment the corresponding view counts across applicable time windows.
  • Flexible Rules: Support capping at different granularities (e.g., ad ID, campaign ID, advertiser ID) over multiple time windows (e.g., rolling 1 hour, rolling 24 hours, calendar day).

Non-Functional Requirements

  • Ultra-low Latency: Ad decisioning operates under strict budgets. The check operation must return within p99 < 10 ms.
  • High Availability: Target 99.999% availability. System degradation must not block the core video streaming playback.
  • High Throughput: Must handle 500,000 QPS peak check requests and up to 50,000 QPS impression recording requests.
  • Consistency Trade-offs: Discuss hard caps vs. soft caps. A small percentage of over-delivery (slight race conditions) is acceptable if it prevents high latency or split-brain stalls.

What to Cover

  1. API Design: Define the contract for ad checking and impression logging.
  2. Data Storage & Counting Mechanism: Choose data structures (e.g., Redis Hashes, Sliding Window Logs, Count-Min Sketch, Sliding Window Counters) and explain storage footprints.
  3. High-Level Architecture: Diagram the interaction between Ad Decision Service, Frequency Capping Service, storage tier, and asynchronous event streams.
  4. Scalability & Partitioning: Explain how you shard user data, handle hot keys, and scale across multi-region deployments.
  5. Failure Modes & Trade-offs: Detail failure policies (fail-open vs. fail-closed) when the service or storage nodes experience partitions or outages.

Hints

Hint 1

Separate the read path (eligibility check before ad selection) from the write path (recording an impression after playback starts), as reads vastly outnumber writes and have stricter latency budgets.

Hint 2

For sliding-window counts at massive scale, consider discrete bucketed counters (e.g., 5-minute sub-windows) rather than storing exact per-impression timestamps to optimize memory and CPU.

Hint 3

Decide whether your counters must be globally synchronized or local to a region, and assess the over-delivery risk of asynchronous replication across data centers.

Follow-up questions

  • How would your design change if an advertiser demands a strict hard cap with financial penalties for any over-delivery?
  • If a live event causes a sudden 10x traffic spike for a specific region, how do you prevent cache hot-spotting on popular device or household IDs?
  • How would you handle household-level frequency capping where multiple user profiles share the same smart TV or living-room device?