Netflix System Design: Real-Time Ad Impression Limiter

You are asked to design a real-time ad impression limiter for a high-throughput advertising system (Netflix-scale). The goal is to enforce per-campaign daily impression caps (e.g., 1M impressions/day) so that once a campaign’s daily limit is reached, the ad is no longer served. Your design should prioritize millisecond-level checks, strong correctness of counts, and high availability across many ad servers.

Core content — what you’ll be asked to deliver:

• Track impressions in real time and increment counters per campaign.
• Check limits synchronously before serving an ad and prevent serving when exceeded (fallback behavior: no ad or alternate creative).
• Reset counters automatically at the start of each day (configurable timezone, e.g., UTC).
• Provide queryable counters for monitoring and debugging, and ensure durability so counts aren’t lost on partial failures.

High-level flow / stages to discuss in the interview:

1. Ad request arrives at an ad server → extract campaign_id.
2. Fast local/cache check (optional) → attempt atomic increment on a distributed counter store (Redis, in-memory sharded counters, or consistent-hash KV).
3. If increment <= limit → serve ad; else → block and serve fallback.
4. Asynchronous aggregation/replication to durable store for long-term durability and analytics.
5. Daily rollover job or TTL-based keys to reset counters by campaign + date.

Skill signals — what you should demonstrate:

• Design of distributed counters (atomic INCR, sharding keys like campaignId:date).
• Consistency vs availability tradeoffs (strong atomic increments vs eventual reconciliation); use of distributed locks or compare-and-swap where necessary.
• Low-latency techniques (local caches, pipelining, client-side batching, memcached/Redis usage) and failure modes.
• Durability and monitoring: write-ahead logs, replication, metrics, alerting, and safe reset strategies across timezones.

Include tradeoffs (e.g., strict global consistency via centralized counters vs partitioned counters with reconciliation), and be prepared to discuss how you would scale to millions of checks/sec and how to recover from partial failures without overserving.