← Netflix Interview Insights

Netflix·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say
May 2026

Summary

Netflix system design round, one big question about frequency capping for an ad platform. Dense topic with a lot of moving parts and I don't think I covered everything they wanted.

Questions Asked (1)

Q1

Design a frequency capping system for an advertising platform that limits how many times a user sees a given ad, campaign, or order within configurable time windows.

System DesignTechnical Trade-offsData Modeling
Author's notes

This one sprawled in every direction the second I started drawing boxes.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: what entities need capping (ad, campaign, order), time windows, and scale. Then design a high-level architecture with a fast lookup store (e.g., Redis) for counters, a rule engine for configurable caps, and a pipeline for logging impressions. Discuss trade-offs between accuracy, latency, and cost, and how to handle distributed counting and eventual consistency.

Pro tip: Emphasize idempotency and atomic operations to avoid over-counting due to retries or concurrent requests, and discuss how to handle time window boundaries (e.g., sliding vs. fixed windows) with minimal memory overhead.

1. Clarify Requirements and Scope

Ask about the entities to cap (ad, campaign, order), the granularity of time windows (hourly, daily, etc.), the expected scale (users, ads, QPS), and whether caps are global or per-user. Also clarify consistency requirements (strict vs. eventual).

2. High-Level Architecture

Propose a system with a fast in-memory store (e.g., Redis) for counters, a rule engine to evaluate caps, and a logging pipeline for impressions. Discuss how the ad server queries the capping service before serving an ad.

3. Data Modeling and Counting Strategy

Design keys for counters (e.g., user_id:ad_id:window_start) and choose between fixed, sliding, or token bucket windows. Explain how to atomically increment and check counters, and how to handle expiration.

4. Scalability and Reliability

Address partitioning (e.g., by user_id), replication, and failover. Discuss how to handle hot keys, and whether to use a distributed cache or a dedicated service. Consider trade-offs between accuracy and performance.

5. Trade-offs and Extensions

Discuss trade-offs: strict vs. eventual consistency, memory vs. accuracy, and cost. Mention extensions like real-time analytics, A/B testing of caps, and integration with other systems (e.g., frequency capping across devices).

Key Points to Mention

  • Use of Redis or similar in-memory store for low-latency counter operations with TTL for automatic window expiration.
  • Atomic operations (e.g., INCR, Lua scripts) to ensure accurate counting under concurrency.
  • Choice of time window strategy: fixed windows (simple, but bursty at boundaries) vs. sliding windows (smoother, but more memory) vs. token bucket (allows bursts).
  • Partitioning and sharding strategy to scale horizontally, e.g., by user ID to keep related counters together.
  • Handling of failures and retries: idempotent impression logging and fallback to approximate counts if the store is unavailable.
  • Configurability: a rule engine or config service that allows dynamic updates to caps without redeployment.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.