Katkat
Back

Design Ad Frequency and Order Tracking

NetflixSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a high-throughput, low-latency distributed counter service for frequency capping and an accurate tracking system for ad order delivery.

Problem Statement

Design a distributed service to manage ad frequency capping and order delivery tracking for a streaming platform. The platform serves millions of concurrent users and must ensure that ads do not exceed specified frequency limits (e.g., "show this ad at most 3 times per 24 hours per user") while accurately recording impressions for billing and pacing purposes.

Functional Requirements

  1. Frequency Capping: Check if an ad can be shown to a user based on previous impressions within a rolling time window.
  2. Impression Logging: Record an impression upon ad display to update frequency counts and order delivery progress.
  3. Order Pacing: Track total impressions served against the contractual order limit to stop delivery once the target is reached.

Non-Functional Requirements

  1. Latency: Frequency checks must be performed in under 20ms at the 99th percentile.
  2. Scalability: Support 100,000+ requests per second.
  3. Consistency: Impression counting must be highly accurate for billing, though minor eventual consistency for frequency capping is acceptable.
  4. Availability: The system should remain operational even if individual storage nodes fail.

Deliverables

  • Describe the high-level system architecture and data flow.
  • Define the data model for storing user-ad impressions and order progress.
  • Propose a strategy for handling concurrency (e.g., race conditions between multiple ad requests for the same user).
  • Explain how the system handles high-volume write traffic while ensuring accurate reporting.

Hints

Hint 1

Consider using an in-memory data store like Redis with time-to-live (TTL) keys for short-term frequency capping, while offloading persistent counts to a durable database.

Hint 2

Use a messaging queue or stream processing framework (e.g., Kafka) to decouple impression ingestion from order-level tracking and billing updates.

Hint 3

For concurrency control, evaluate optimistic locking or atomic increment operations at the cache layer to prevent over-delivery of ads.

Follow-up questions

  • How would you handle a scenario where the network partition prevents the ad-server from updating the central tracking store?
  • If the advertiser changes the total order limit halfway through a campaign, how do you propagate this change to the pacing service without stopping active ads?
  • How does your design change if you need to support privacy-safe identifiers instead of persistent user IDs?