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

SeniorPrefer not to say

May 2026Remote

Summary

Netflix system design round, one meaty question about ad frequency capping that spiraled into a pretty deep discussion on distributed counters and consistency trade-offs. Left feeling like I covered the basics but probably didn't go far enough on the cross-datacenter stuff.

Questions Asked (1)

Design a frequency capping service for online ads, where a user should not be shown the same ad or campaign more than N times within a configurable time window (per hour, per day, or per campaign lifetime). Cover the real-time cap check on the ad-serving path, reliable impression recording, storage choices, and consistency trade-offs at scale.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started with Redis and sliding window counters which felt right, but then the interviewer pushed on what happens across datacenters and I kind of stumbled.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: scale (QPS, number of users/ads), cap granularity (per ad, per campaign), time windows (hourly, daily, lifetime), and latency budget. Then design a two-part system: a low-latency read path for cap checks and a reliable write path for impression recording, using a fast store like Redis with appropriate data structures and an async pipeline to a durable store. Discuss consistency trade-offs (e.g., eventual vs. strong consistency) and how to handle failures and scale.

Pro tip: Emphasize that frequency capping is a best-effort system: slight over-serving due to eventual consistency is often acceptable, but under-serving (blocking ads incorrectly) can hurt revenue. Propose a design that favors availability and low latency, with idempotent impression recording and reconciliation to correct counts.

1. Clarify Requirements and Scale

Ask about QPS, number of active users and ads, cap definitions (per ad vs. per campaign), time windows, and latency SLA. Determine acceptable consistency (e.g., can we tolerate a few extra impressions?).

2. Design the Real-Time Cap Check

Outline a low-latency read path: on ad request, fetch current counts for the user-ad/campaign from a fast store (e.g., Redis) and compare against caps. Use caching and local aggregation to reduce load.

3. Design Reliable Impression Recording

After an ad is served, record the impression asynchronously via a message queue (e.g., Kafka) to decouple from the serving path. Ensure idempotency and at-least-once processing, with deduplication.

4. Choose Storage and Data Model

Use Redis with counters and TTLs for real-time counts (e.g., key per user-ad-window). Persist raw impressions in a durable store (e.g., Cassandra, Bigtable) for analytics and reconciliation. Consider time-bucketed keys for efficient windowing.

5. Address Consistency and Scale Trade-offs

Discuss eventual consistency: counts may lag, leading to slight over-serving. Mitigate with short TTLs, periodic reconciliation from durable store, and sharding by user ID. Handle failures with retries and fallbacks.

Key Points to Mention

Use Redis with atomic INCR and EXPIRE for real-time counters, keyed by user, ad/campaign, and time window (e.g., hourly buckets).
Asynchronous impression recording via a message queue to avoid blocking ad serving; ensure idempotency with unique impression IDs.
Time-bucketed keys (e.g., user:ad:hour) to handle sliding windows and simplify TTL management.
Trade-off: eventual consistency may allow a few extra impressions, but strong consistency would add latency and reduce availability.
Sharding by user ID to scale horizontally; use local caching or read replicas to reduce Redis load.
Reconciliation job to periodically correct counts from durable storage and handle missed events.

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