Design a frequency-capping service for an advertising platform. Before an ad impression is served, the caller asks whether a user has already seen a campaign too many times within a configured time window. After serving, the caller records the impression. Support caps such as "at most three impressions per user and campaign in 24 hours." Campaign configuration can change, events may be retried, and multiple serving regions can make decisions concurrently. ### Constraints & Assumptions - The decision path must remain low latency. - Duplicate impression events must not inflate counts. - State must expire when it can no longer affect any active cap. - Define whether a rare cap overshoot is allowed; give a stricter design if it is not. ### Clarifying Questions to Ask - Are windows fixed, calendar-aligned, or sliding? - Does the cap apply per campaign, creative, account, or a hierarchy of all three? - How quickly must configuration changes take effect? ```hint Make the race explicit A separate read followed by a write can let concurrent requests pass the same final slot. ``` ### What a Strong Answer Covers - A key model, window representation, atomic check-and-increment operation, and TTL policy. - Idempotent event handling and a clear consistency-versus-availability decision across regions. - Configuration versioning, hot-key protection, observability, and reconciliation from durable impression facts. ### Follow-up Questions - How would you enforce a campaign cap and an advertiser-wide cap in one decision? - How would you backfill counts after discovering delayed impression events? - What happens during a regional partition?